Nel contesto della metodologia Agile in ingegneria del software, la pratica CI/CD è considerata una best practice in quanto consente ai team di sviluppo software di concentrarsi sulla conformità ai requisiti aziendali, alla qualità del codice e alla sicurezza poiché le fasi di implementazione sono automatizzate. L’integrazione Continua (CI) e la Consegna Continua (CD) rappresentano una cultura, un insieme di principi operativi e una raccolta di pratiche che consentono ai team di sviluppo software di fornire modifiche al codice più frequentemente e in modo affidabile. L’implementazione è anche nota come pipeline CI / CD.
Continuous integration o Integrazione Continua (CI)
L’Integrazione Continua è una filosofia di codifica e un insieme di pratiche che guidano i team di sviluppo a implementare piccole modifiche e controllare frequentemente il codice nei repository di controllo versione. Poiché la maggior parte delle applicazioni moderne richiede lo sviluppo di codice in piattaforme, il team ha bisogno di un meccanismo per integrare e convalidare le sue modifiche.
L’obiettivo tecnico di CI è stabilire un modo coerente e automatizzato per compilare, impacchettare e testare le applicazioni. Con coerenza nel processo di integrazione in atto, è più probabile che i team eseguano più frequentemente modifiche al codice, il che porta a una migliore collaborazione e qualità del software.
Nello sviluppo di applicazioni innovative, l’obiettivo è quello di avere più sviluppatori che lavorino simultaneamente su diverse funzioni della stessa applicazione. Se, tuttavia, un’organizzazione prevede di unificare tutte le diramazioni del codice sorgente in un’unica giornata (il cosidetto “merge day”), le attività manuali che ne risultano possono essere noiose 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.
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.
Continuous Delivery o Consegna Continua (CD)
La Consegna Continua riprende dove finisce l’integrazione continua (CI). E’ un modello, introdotto nello sviluppo software, per eseguire contemporaneamente le fasi di sviluppo, rilascio, feedback e gestione della qualità in brevi intervalli e in un ciclo continuo. In questo modo, lo sviluppo diventa più efficiente e il cliente riceve prima il prodotto, anche quando questo non è ancora pronto. La Continuous Delivery fornisce feedback allo sviluppatore sulla base di test automatizzati che controllano principalmente il build ogniqualvolta viene modificato il codice sorgente.
In che modo l’integrazione continua migliora la collaborazione e la qualità
L’integrazione continua è una filosofia di sviluppo supportata dalla processi automatizzati. Quando si esercitano in CI, gli sviluppatori inseriscono frequentemente il proprio codice nel repository di controllo versione e la maggior parte dei team ha uno standard minimo di commit del codice almeno ogni giorno. La logica alla base di ciò è che è più facile identificare difetti e altri problemi di qualità del software su differenziali di codice più piccoli piuttosto che su quelli più grandi sviluppati in un lungo periodo di tempo. Inoltre, quando gli sviluppatori lavorano su cicli di commit più brevi, è meno probabile che più sviluppatori modifichino lo stesso codice e richiedano l’unione durante il commit.
I team di sviluppo che praticano l’integrazione continua utilizzano diverse tecniche per controllare quali funzioni e codice sono pronti per la produzione.
Molti utilizzano flag di funzionalità, un meccanismo di configurazione per attivare o disattivare funzionalità e codice in fase di esecuzione. Le funzionalità che sono ancora in fase di sviluppo sono racchiuse con flag di funzionalità nel codice, distribuite con il ramo master in produzione e disattivate fino a quando non sono pronte per l’uso.
Un’altra tecnica per la gestione delle funzionalità è la diramazione del controllo versione. Una strategia di branching è selezionata per definire i protocolli su come il nuovo codice viene unito in rami standard per sviluppo, test e produzione. Vengono creati rami di funzionalità aggiuntivi per quelli che richiedono cicli di sviluppo più lunghi. Al termine della funzionalità, gli sviluppatori possono quindi unire le modifiche dai rami delle funzionalità al ramo di sviluppo primario. Questo approccio funziona bene, ma può diventare difficile da gestire se ci sono molte funzioni sviluppate contemporaneamente.
Il processo di compilazione stesso viene quindi automatizzato impacchettando tutto il software, il database e altri componenti. Ad esempio, se si stava sviluppando un’applicazione Java, CI impacchetta tutti i file del server Web statico come HTML, CSS e JavaScript insieme all’applicazione Java e agli eventuali script del database. Inoltre l’automazione eseguirà anche unit test e altri test.
La maggior parte degli strumenti CI / CD consente agli sviluppatori di avviare build su richiesta, attivate da commit del codice nel repository di controllo versione o in base a una pianificazione definita. I team devono discutere il programma di build che funziona meglio per le dimensioni del team, il numero di commit giornalieri previsti e altre considerazioni sull’applicazione. Una best practice per garantire che i commit e le build siano veloci, altrimenti potrebbe impedire il progresso dei team che cercano di sviluppare in maniera Agile.
Conclusioni
CI / CD è un best practice DevOps perché affronta il disallineamento tra gli sviluppatori che vogliono apportare frequenti cambiamenti, con le operazioni che vogliono applicazioni stabili. Con l’automazione in atto, gli sviluppatori possono inviare le modifiche più frequentemente. I team operativi vedono una maggiore stabilità perché gli ambienti hanno configurazioni standard, sono previsti test continui nel processo di consegna, le variabili di ambiente sono separate dall’applicazione e le procedure di rollback sono automatizzate.
L’impatto dell’implementazione di pipeline CI / CD può essere misurato come indicatore di prestazioni chiave (KPI) di Devops. KPI come la frequenza di implementazione, i tempi di consegna dei cambiamenti e il tempo medio di recupero (MTTR) da un incidente sono spesso migliorati quando viene implementato CI / CD con test continui. Tuttavia, CI / CD è solo un processo che può guidare questi miglioramenti e ci sono altri prerequisiti per migliorare le frequenze di distribuzione.
Per iniziare con CI / CD è necessario che il team di sviluppo e il team operativo collaborino su tecnologie, pratiche e priorità. I team devono sviluppare il consenso sugli approcci giusti per le loro attività e tecnologie, in modo che, una volta che CI / CD è stato messo in atto, il team sia integrato con le seguenti pratiche in modo coerente.
