Caratteristiche e differenza tra Continuous Delivery e Continuous Deployment

Continuous Integration è una pratica pensata per gli sviluppatori, dato che tratta solo di come verificare il lavoro prodotto da loro. DevOps però vede all’interno del processo di realizzazione del software anche i membri del settore IT: per questo le pratiche utilizzate all’interno della metodologia DevOps sono Continuous Delivery (CD) e Continuous Deployment, le quali comprendono i concetti di Continuous Integration aggiungendone però altri.
Lo scopo di CD consiste nel partire dal codice prodotto dallo sviluppatore e, attraverso una pipeline, arrivare al prodotto funzionante e pronto per l’esecuzione. I passaggi della pipeline, all’interno di CD, sono per la maggior parte automatici e dunque immediati. Per tale motivo, la pipeline dovrebbe essere eseguita più volte al giorno quando si inserisce del nuovo codice all’interno del SCM.
Una possibile pipeline per effettuare CD è mostrata nella figura seguente.

Come è possibile osservare, nella prima parte della pipeline, quella in blu, sono presenti tutti gli passi contenuti anche in Continuous Integration, mentre nella parte restante sono presenti tutte le fasi per il deposito del prodotto e la sua messa in produzione. Tutti i passaggi da una fase all’altra contengono anche messaggi automatici di feedback, fondamentali nella metodologia DevOps, eccetto le ultime due fasi. È proprio questa la differenza tra Continuous Delivery e Contunuous Deployment: la prima prevede che le fasi di deposito degli artefatti e la loro messa in produzione siano eseguite manualmente, mentre nella seconda tali fasi vengono eseguite in automatico.
Per lavorare attraverso Continuous Delivery, l’informatico Martin Fowler afferma che devono essere presenti le seguenti caratteristiche nel ciclo di vita del software:
In qualsiasi momento, il prodotto deve trovarsi nello stato di poter essere messo in produzione;
L’intero team, formato dal settore dello sviluppo e produzione software, deve avere la priorità di mantenere una versione del software facilmente rilasciabile;
Ognuno deve poter ricevere rapidamente feedback in modo automatico appena viene apportata una modifica al software:
Deve essere presente un singolo comando che possa mettere in produzione una qualsiasi versione del software che si desideri, in tutti gli ambienti di distribuzione.

Per mettere in pratica tutti i passaggi che richiede DevOps e Continuous Delivery sono necessari strumenti specifici che si occupino singolarmente delle varie fasi della pipeline sopra descritta. Essi sono:

• SCM: acronimo di Source Code Managment, un software per mantenere le versioni del codice prodotto e per rendere disponibile un ambiente di lavoro condiviso, ad esempio GitHub o GitLab;
• Software per la build automation: un software per eseguire la build del codice, ad esempio Maven o Gradle;
• Framework per eseguire i test: un framework che possa eseguire i test creati dagli sviluppatori, ad esempio JUnit o PyTest;
• Orchestratore: un software in cui si possa configurare ed eseguire la pipeline per Continuous Delivery, ad esempio Jenkins;
• Artifact Repository: un software per mantenere le versioni dei file in binario del software testato e compilato, ad esempio Artifactory o DockerHub;
• Conftguration managment: un software che possa mantenere le configurazioni dei vari ambienti in cui verrà utilizzato e prodotto il software, ad esempio Ansible;
• Software per il monitoraggio della pipeline: software che sappia analizzare le prestazioni della pipeline ed avvisare con dovute notifiche in caso di problemi.

Prendendo spunto dagli step presenti nella figura precedente, i software utilizzati durante un possibile sviluppo software per costruire la pipeline per effettuare Continuous Delivery sono sicuramente:

• Code: GitHub e GitLab;
• Build: Maven e Gradle;
• Test: Junit;
• Release: Jenkins;
• Deploy: Docker.