Caratteristiche e differenza tra Continuous Integration, Continuous Delivery e Continuous Deployment nello sviluppo software

Continuous Integration, Continuous Delivery e Continuous Deployment

Per avere la possibilità di eseguire più release in un giorno è necessario avere a disposizione un meccanismo che permetta, in tempi brevi e con un alto livello di confidenza, di decidere se l’aggiunta o la modifica di una funzionalità siano pronte per essere messe in produzione. Questa verifica viene effettuata dalle cosiddette Continuous Integration e Continuous Delivery o Continuous Deployment (CI/CD).
Prima di essere pronta al deployment, ogni nuova versione deve attraversare una serie di ambienti di test chiamata deployment pipeline. Ad ogni stadio, la versione viene testata in un ambiente sempre più simile all’ambiente di produzione, per verificarne gradualmente il grado di correttezza. Solo una volta che tutti i test sono superati, la nuova versione pùo essere considerata valida. Si noti che ogni azienda è libera di scegliere come comporre la propria pipeline a seconda delle necessità richieste dal progetto.

Ambienti

Fino ad ora si è parlato di ambienti senza darne una definizione precisa. Per ambiente si intende un insieme di risorse computazionali sufficienti a eseguire un sistema software, inclusi tutti i software di supporto, i dati, le comunicazioni di rete, le configurazioni e le entità esterne necessarie a eseguire il sistema stesso. Ciascun ambiente è tipicamente separato dagli altri e non condivide risorse con essi, se non quelle in sola lettura. Quest’ultima caratteristica è fondamentale ai fini della CI/CD. Se, ad esempio, l’ambiente in cui l’applicazione viene testata condividesse il database con l’ambiente di produzione, si potrebbero modificare dati reali dell’applicazione, compromettendoli.

L’astrazione di ambiente consente di avere configurazioni diverse nei vari stage della pipeline. Per esempio, l’ambiente in cui ciascuno sviluppatore testa l’applicazione prima di eseguire un commit utilizzerà un livello di logging molto più verboso rispetto a quello di produzione, per facilitare la ricerca e la correzione di bug. Nonostante questa flessibilità di configurazione sia di grande aiuto, abusarne potrebbe rendere gli ambienti di test troppo differenti rispetto a quello di produzione e influire sul comportamento del sistema.

Continuous Integration

In passato gli sviluppatori aspettavano lunghi periodi di tempo prima di integrare le proprie modifiche con quelle degli altri membri del team. Di conseguenza, il lavoro di integrazione risultava spesso faticoso, soggetto all’errore.
Con la Continuous Integration (CI) i membri di un team aggiungono regolarmente modifiche ad un repository centralizzato (usando un sistema di version control, ad esempio git). Ad ogni nuovo commit, le nuove modifiche vengono intercettate da un server specializzato (CI server), dove un tool automatico esegue una build e una serie di unit test per verificare che la nuova modifica non contenga errori. Se si riscontrano problemi (il codice non compila o non supera i test) il commit viene rifiutato e lo sviluppatore riceve indicazioni su quali errori sono stati rilevati. In caso contrario la build pùo continuare il percorso all’interno della pipeline.
La CI costituisce il primo stadio della deployment pipeline ed è di fondamentale importanza per ridurre i tempi di convalida e per risolvere tempestivamente i bug.

Continuous Delivery

Una volta superata la fase iniziale di integrazione e di test, la build completa viene fatta passare attraverso un certo numero di ambienti per essere testata ulteriormente. Obiettivo della Continuous Delivery (CD) è decidere, con un alto grado di confidenza, se la versione corrente sia pronta per essere messa in produzione o meno. In questo modo si avrà sempre a disposizione una build pronta per il deployment finale.
Ogni ambiente è progressivamente più simile all’ambiente di produzione e prevede test sempre più restrittivi, ma anche più lenti. Non si eseguono più semplici unit test, ma test dell’interfaccia, test delle performance, test di integrazione, test di regressione e così via. La scelta di eseguire le tipologie di test in ordine crescente di tempo permette di rendere più immediato il processo di bug-fixing. In questo modo se si riscontrano bug per un certo stadio della pipeline, non sarà necessario eseguire i test per gli stadi successivi, accorciando ulteriormente i tempi. E’ importante sottolineare che, in alcuni casi e per rendere l’intero processo più rapido, alcuni stadi possono essere eseguiti parallelamente, mantenendo tuttavia l’isolamento tra gli ambienti.
Se la build supera tutti gli stadi della pipeline, viene considerata valida per il deployment. A questo punto l’organizzazione ha due possibilità: potrebbe decidere di dispiegare automaticamente ogni versione che supera la deployment pipeline (in tal caso si parla di Continuous Deployment) oppure scegliere manualmente. In entrambi i casi la continuous delivery rende tale decisione una semplice scelta di business.

Continuous Deployment

La Continuous Deployment va oltre la continuous delivery. Con questa pratica, ogni modifica che supera tutte le fasi della pipeline di produzione viene rilasciata ai tutti i tuoi clienti. Non c’è alcun intervento umano e solo un test fallito impedirà che una nuova modifica venga implementata nella produzione.
La Continuous deployment è un modo eccellente per accelerare il ciclo di feedback con i tuoi clienti e fare pressione sul team di sviluppo perché non c’è più un giorno di rilascio. Gli sviluppatori possono concentrarsi sulla creazione di software e vedono il loro lavoro “in diretta” pochi minuti dopo aver finito di lavorarci.