Continuous Integration e Continuous Delivery, abbreviata in CI/CD, è una metodologia nata per risolvere le esigenze dei team DevOps, che devono frequentemente integrare e rilasciare nuovo codice ed aggiornamenti.

Per ogni azienda è infatti molto importante, se non vitale, innovare continuamente i propri prodotti, applicazioni e servizi. Altrettanto decisiva è l’adozione di tecnologie e strumenti moderni nella costruzione di un’offerta che si differenzi dalla concorrenza e rimanga al passo con i tempi, in un mercato dove i clienti sono sempre più esigenti e si abituano velocemente ad usare nuove tecnologie ed interfacce evolute nei software e nei servizi digitali.

La CI/CD si basa su strumenti e processi, che, rendendo la fase di deploy più automatizzata possibile, permettono di superare le problematiche che si possono verificare negli scenari in cui lo sviluppo di software avviene in parallelo, suddiviso in moduli ed affidato a team specializzati.

I concetti alla base di Continuous Integration e Continuous Delivery

Per Continuous Integration si intende la parte del processo a carico dei programmatori che si occupano di effettuare sviluppo, integrazione test di funzionamento e inserimento del nuovo codice all’interno dell’applicativo. Naturalmente è previsto che possano operare più sviluppatori o team in parallelo, procedendo con automatismi che verifichino la correttezza di funzionamento finale. La Continuous Integration è basata normalmente su sistemi di controllo della versione del software e comporta un frequente allineamento del lavoro prodotto da più programmatori.

Continuous Delivery ha in realtà un duplice significato, riferendosi sia all’aspetto di distribuzione continua di aggiornamenti del software, sia alla organizzazione dello sviluppo continuo svolto dai team. In generale, la distribuzione continua è un processo che permette la verifica automatica delle modifiche fatte al codice mettendo in luce eventuali bug per poi caricare in un archivio, o repository, il codice aggiornato e testato. Questa sorta di pacchetto software, chiamato anche artefatto, è il prodotto finale destinato al sistema del cliente o della propria azienda, e può assumere varie forme: dalla procedura di installazione vera e propria, ad un semplice archivio compresso in formato Zip.

La fase finale, detta anche Continuous Deployment, conclude il flusso di lavoro e comporta che la messa in opera del codice aggiornato e testato avvenga in un tempo molto limitato con un processo automatizzato, il tutto senza bisogno di coinvolgere, a differenza di quanto accadeva in passato, personale specializzato sugli aspetti della piattaforma operativa e limitando procedure manuali spesso delicate e complesse. A volte tale operazione viene eseguita in pochi minuti, praticamente senza intervento di risorse umane.

I vantaggi della pipeline Continuous Integration e Continuous Delivery

Il flusso di operazioni descritto è chiamato Pipeline CI/CD ed è alla base dei moderni sistemi, perché organizza ed automatizza le fasi di creazione, assemblaggio (build), verifica e rilascio (deploy) di codice, limitando al massimo la separazione tra il team di sviluppo (“Dev”) ed i team operativi (“Ops”). Questo permette una migliore sinergia basata sulla ripartizione degli incarichi, dei flussi di lavoro e l’adozione di strumenti e metodologie standard ben collaudate.

La fase di sviluppo si basa sull’adozione condivisa di strumenti che permettono il controllo dei cambiamenti apportati dai singoli programmatori o team tramite strumenti ormai ben conosciuti e largamente adottati, quali per esempio GIT, utile per gestire e tenere sotto controllo gli aggiornamenti di progetti di ogni dimensione e complessità. Un altro degli strumenti più utilizzati attualmente in infrastrutture di tipo on premise è il server di automazione Jenkins, distribuito con licenza Open Source, che offre centinaia di strumenti e plugin per realizzare, testare e automatizzare lo sviluppo dei progetti.

La fase Continuous Delivery, che segue quella di sviluppo vera e propria, comporta il caricamento del codice con integrazioni ed aggiornamenti in un ambiente di staging in cui viene simulato l’ambiente di produzione. Qui il software viene testato in una situazione realistica, perfettamente aderente ed allineata con quanto attualmente in opera. Tramite procedure automatiche viene testato a fondo nel funzionamento, anche in condizione di vari livelli di carico. Per questo scopo, si usano spesso dei veri e propri framework come per esempio Selenium, che è composto da vari strumenti per offrire la possibilità di testare contemporaneamente su varie macchine e con vari browser il comportamento del software applicativo.

Uno dei numerosi vantaggi della successiva fase di Continuous Deployment consiste nell’evitare che il personale debba eseguire la pubblicazione tipicamente di notte o nei giorni festivi per evitare sospensioni del funzionamento, dato che la procedura automatica può essere pianificata per essere eseguita in orari “non critici” senza alcun intervento manuale.

Attualmente esistono molti strumenti per creare una pipeline CI/CD, tra software e servizi online come quelli offerti, per esempio, anche da Amazon AWS. Orientarsi nella scelta tra soluzioni on-premise e cloud adeguate alle proprie esigenze non è sempre facile. Per questo motivo, è di fondamentale importanza affidarsi ad un partner che abbia il necessario know-how per decidere quali strumenti implementare per gestire al meglio l’eventuale modernizzazione della struttura attuale o la migrazione totale verso una struttura basata su CI/CD. Il risultato di implementare processi automatizzati è un maggiore controllo su quanto si produce a livello di funzionalità, servizi ed interfaccia, e permette di sviluppare più velocemente e agevolmente, riducendo al minimo le differenze di metodologie di lavoro tra i vari gruppi di sviluppo.

Risulta possibile realizzare, testare ed applicare perfino piccole modifiche, una per volta, senza dovere aggiornare in modo manuale l’intero applicativo. Anche i piccoli moduli possono essere testati non appena integrati nei repository di codice, verificando l’effettiva rispondenza con le richieste di partenza oltre che la correttezza di funzionamento. Uno dei paradigmi adottati nella realizzazione di una pipeline CI/CD consiste proprio nel cosiddetto Fault Isolations, ovvero limitare l’area di funzionamento di un singolo modulo in modo che in un applicativo articolato e complesso sia comunque facile isolare e correggere un eventuale problema.

Adottare il paradigma del Continuous Integration and Continuos Delivery significa anche avere un più veloce, praticamente continuo, flusso di feedback non soltanto dai clienti ed utilizzatori del software, ma anche da parte dei team di sviluppo, con una maggiore trasparenza nei flussi di lavoro e la responsabilizzazione dei singoli team o sviluppatori verso un modulo della pipeline. Risulta più semplice rilevare non solo malfunzionamenti, ma anche “colli di bottiglia” ed inefficienze, per pianificare meglio i carichi di lavoro necessari ad implementare e distribuire aggiornamenti nei tempi richiesti.