Cosa si intende con CI/CD?

CI/CD è un metodo per la distribuzione frequente delle app ai clienti, che prevede l'introduzione dell'automazione nelle varie fasi di sviluppo applicativo. Si basa principalmente sui concetti di integrazione, distribuzione e deployment continui. L'approccio CI/CD supera le difficoltà legate all'integrazione di nuovo codice, una situazione così problematica per i team operativi e di sviluppo da essere denominata "inferno dell'integrazione".

Nello specifico, il metodo CI/CD introduce l'automazione costante e il monitoraggio continuo per tutto il ciclo di vita delle applicazioni, dalle fasi di integrazione e test a quelle di distribuzione e deployment. Tali processi interconnessi, che insieme formano quella che viene spesso definita "pipeline CI/CD", sono supportati da team operativi e di sviluppo che collaborano secondo una metodologia agile con un approccio DevOps o site reliability engineering (SRE).

Gli acronimi CI e CD possono assumere vari significati. In CI/CD "CI" si riferisce sempre all'integrazione continua, un processo di automazione per gli sviluppatori. Per la riuscita dell'integrazione continua, le nuove modifiche apportate al codice dell'app vengono regolarmente compilate, testate e unite in un repository condiviso. risolvendo così il problema dei conflitti tra le numerose diramazioni di un'applicazione in fase di sviluppo.

"CD" può indicare invece la distribuzione continua e/o il deployment continuo, concetti correlati e usati di frequente in modo intercambiabile. Entrambi prevedono l'automazione delle fasi successive della pipeline, ma sono a volte usati distintamente per indicare il livello di automazione applicato.

Con distribuzione continua si intende il processo con il quale le modifiche apportate da uno sviluppatore all'applicazione vengono automaticamente testate alla ricerca di bug e caricate in un repository (come GitHub o un registro per container), dal quale vengono distribuite in un ambiente di produzione dai team operativi. È una soluzione al problema della scarsa visibilità e comunicazione tra i team di sviluppo e quelli operativi. In questo senso la distribuzione continua ha il fine di garantire interventi manuali minimi per distribuire il nuovo codice.

L'altra definizione possibile per "CD", deployment continuo, può riferirsi al rilascio automatico delle modifiche apportate dallo sviluppatore dal repository alla produzione, dove diventano fruibili ai clienti. In tal modo, si evita di sovraccaricare i team operativi con procedure manuali, che altrimenti rallenterebbero la distribuzione delle applicazioni. Sfrutta quindi i vantaggi della distribuzione continua, automatizzando la fase successiva della pipeline.

In alcuni casi, CI/CD specifica solo le procedure correlate di integrazione continua e distribuzione continua, ma può anche indicare tutte e tre le pratiche, includendo anche il deployment continuo. A complicare il tutto, a volte l'uso di "distribuzione continua" sottintende anche i processi di deployment continuo.

Non è sempre necessario perdersi in queste sfumature semantiche: è sufficiente ricordare che con CI/CD si intende un processo, spesso visualizzato come flusso, che prevede l'aggiunta di un elevato livello di automazione costante e di un monitoraggio continuo allo sviluppo delle applicazioni.

L'esatto significato del termine dipenderà, di volta in volta, dalla quantità di automazione integrata nel flusso di CI/CD. Molte aziende iniziano aggiungendo l'integrazione continua per poi automatizzare distribuzione e deployment in corso d'opera, ad esempio come parte di applicazioni cloud native.

I nostri esperti possono aiutare la tua azienda a sviluppare le procedure, gli strumenti e la cultura necessari a rinnovare in modo più efficiente le tue applicazioni esistenti e realizzarne di nuove.

Nello sviluppo di applicazioni innovative, l'obiettivo è quello di avere più sviluppatori che lavorino simultaneamente su diverse funzioni della stessa app. Se, tuttavia, un'organizzazione prevede di unificare tutte le diramazioni del codice sorgente in un'unica giornata (definita dagli sviluppatori come "merge day"), le attività che ne risultano possono essere noiose, manuali ed esigenti in termini di tempo. Ciò accade quando uno sviluppatore apporta, in modo indipendente, modifiche all'applicazione che sono divergenti da quelle completate simultaneamente da altri sviluppatori. Il problema può essere ulteriormente complicato dal fatto che ogni sviluppatore ha personalizzato il proprio ambiente di sviluppo integrato (IDE) locale, invece di concordare con il team un IDE unico, basato su cloud.

Adottando l'integrazione continua, gli sviluppatori possono riportare le modifiche apportate al codice in un'unica diramazione (o ramo) condivisa con frequenza maggiore, a volte anche quotidianamente. Una volta unificate, le modifiche vengono convalidate tramite la compilazione automatica dell'applicazione e l'esecuzione di diversi livelli di test automatici, in genere test di unità e integrazione finalizzati a garantire che le modifiche non abbiamo causato danni. Nella fase di test viene esaminato ogni elemento costituente l'intera applicazione, dalle classi alle funzioni fino ai vari moduli. Se viene individuato un conflitto tra il codice nuovo e quello esistente, l'integrazione continua ne agevola la correzione.

Successivamente all'automazione delle build e ai test di integrazione e unità previsti da CI, la distribuzione continua automatizza il rilascio del codice convalidato in un repository. Ne consegue che, perché il processo di distribuzione continua sia efficace, è importante che il CI sia già integrato nella pipeline di sviluppo. Obiettivo della distribuzione continua è disporre di un code base sempre pronto a essere distribuito in un ambiente di produzione.

Nella distribuzione continua, ogni fase, dall'unione delle modifiche al codice alla distribuzione di build production ready, prevede l'automazione dei test e del rilascio del codice. Al termine del processo il team operativo è in grado di eseguire il deployment di un'app in produzione in modo rapido e semplice.

La fase conclusiva di una pipeline CI/CD matura è il deployment continuo. Come estensione della distribuzione continua, che automatizza il rilascio di una build production ready in un repository di codice, il deployment continuo automatizza il rilascio dell'app in produzione. Non essendoci alcun blocco manuale nelle fasi della pipeline prima della produzione, il deployment continuo deve necessariamente fare affidamento su un'automazione dei test ben progettata.

Nella pratica, il deployment continuo fa sì che la modifica apportata da uno sviluppatore a un'applicazione cloud che supera tutti i test automatizzati può diventare effettiva pochi minuti dopo la sua scrittura. Grazie a questo metodo, ricevere e integrare i feedback inviati dagli utenti con cadenza costante è più facile. Nel complesso, queste procedure di CI/CD interrelate rendono lo sviluppo di un'applicazione meno rischioso, perché consentono di rilasciare le modifiche alle applicazioni in piccole parti e non tutte insieme. Implicano tuttavia un forte impegno iniziale, poiché è necessario scrivere test automatizzati che siano adatti alla vasta gamma di fasi di test e rilascio previste dal flusso CI/CD.

Gli strumenti CI/CD possono essere utili per automatizzare lo sviluppo, il deployment e i test. Alcuni strumenti gestiscono specificamente l'aspetto dell'integrazione (CI), alcuni gestiscono sviluppo e deployment (CD), altri sono specifici per i test continui o le funzioni correlate.

Uno degli strumenti open source più noti per CI/CD è il server di automazione Jenkins, progettato per gestire qualsiasi elemento da un semplice ferro per di integrazione continua a un hub completo di distribuzione continua.

Tekton Pipelines è un framework di CI/CD per piattaforme Kubernetes che offre un'esperienza CI/CD cloud native standard con container.

Oltre a Jenkins e Tekton Pipelines, tra gli altri strumenti CI/CD open source che può essere utile approfondire si annoverano:

• Spinnaker, una piattaforma CD pensata per gli ambienti multicloud.

• GoCD, un server CI/CD incentrato sulla modellazione e sulla visualizzazione.

• Concourse, "una risorsa continua open source".

• Screwdriver, una piattaforma di creazione progettata per CD.

Per i team può essere utile prendere in considerazione il ricorso a strumenti CI/CD gestiti, disponibili da una serie di fornitori diversi. Tutti i principali provider di cloud pubblico offrono soluzioni CI/CD, insieme a GitLab, CircleCI, Travis CI, Atlassian Bamboo e molti altri.

Inoltre, tutti gli strumenti essenziali per DevOps possono far parte di un processo CI/CD. Gli strumenti per l'automazione della configurazione (come Ansible, Chef e Puppet), i runtime dei container (come Docker, rkt e cri-o) e l'orchestrazione dei container (Kubernetes) non sono strettamente strumenti CI/CD, ma sono presenti in molti flussi di lavoro CI/CD.