Gli obiettivi di DevOps e del continuous delivery trovano molti punti in comune, basati sullo sviluppo del software attraverso un workflow agile e continuativo teso ad eliminare le discontinuità e le lentezze della programmazione tradizionale, basata su un’architettura del software di tipo monolitico.

Le organizzazioni che basano lo sviluppo delle loro applicazioni sui principi di DevOps utilizzano correntemente il continuous delivery per ottenere una serie di benefici diffusi quanto inequivocabili, generalmente focalizzati su una distribuzione del software rapida e di qualità elevata.

Vediamo in cosa consiste il continuous delivery, come funziona e perché è spesso associato alla continuous integration.

Continuous delivery: cos’è e come funziona

Il continuous delivery (CD) è un approccio per il rilascio del software in cui i team di sviluppo creano e testano il codice attraverso cicli brevi e frequenti, con procedure che prevedono generalmente un elevato livello di automazione, per migliorare progressivamente nel tempo la qualità dell’applicazione.

La particolarità di questo metodo è quella di consentire ai team di sviluppo di effettuare cicli di build, test and deploy basati su un approccio di tipo incrementale, operando su poche novità alla volta, senza dover necessariamente riscrivere l’applicazione nel suo insieme, come avveniva nelle procedure di tipo tradizionale.

Come accennato in sede di premessa, il continuous delivery va a braccetto con la metodologia DevOps, che sposa quasi sempre un altro metodo noto come continuous integration (CI), che con il CD forma la nota pipeline CI/CD, fortemente personalizzabile e adattabile alle esigenze di moltissime catene di sviluppo.

Nella distribuzione continua, i test prevedono la verifica di tutti gli aspetti legati alla funzionalità, per ridurre il rischio di imprevisti nell'ambiente di produzione. Una delle qualità che gli sviluppatori apprezzano maggiormente del CD è proprio la sua capacità di “shift left”, di anticipare, tutte le fasi di test, in modo da offrire il prima possibile tutti i feedback necessari per fixare i bug e ottimizzare il codice, arrivando più rapidamente possibile al deploy.

I componenti che superano i test automatizzati previsti dai team di sviluppo diventano validabili per il rilascio. In questa fase finale, il continuous delivery può prevedere una supervisione umana e una distribuzione manuale. In alternativa, la compilazione può essere distribuita automaticamente.

Il software moderno: dall’architettura monolitica ai microservizi

Metodi come continuous delivery vengono utilizzati nell’ambito dello sviluppo dei microservizi, un approccio architetturale che prevede la decomposizione dell’applicazione principale (monolite) in vari moduli funzionali tra loro disaccoppiati. È proprio il disaccoppiamento tra i vari componenti del software consente ai team DevOps di articolare le loro unità di sviluppo senza che vi sia una dipendenza tecnologica, ad esempio per quanto concerne i linguaggi di programmazione. Inoltre, quando si rende necessario aggiornare un modulo funzionale, ad esempio il catalogo prodotti di un e-commerce, l’intervento riguarderà soltanto il team predisposto a farlo, senza interessare ad esempio funzioni che non necessitano di modifiche, come il sistema di pagamento online, la gestione del carrello o l’evasione degli ordini.

I microservizi, nel processo di continuous delivery, vengono sottoposti al ciclo di build, test e deploy e tra loro connessi mediante delle API (application programming interface), specifiche interfacce che consentono di far comunicare le applicazioni disaccoppiate secondo una logica unitaria.

L’architettura a microservizi ha rappresentato per molti un passo obbligato quando si è trattato di sviluppare la prima applicazione cloud native, un contesto in cui la tradizionale architettura monolitica, che prevede l’aggiornamento in toto ad ogni rilascio funzionale, non appare più sufficientemente agile per reggere i ritmi imposti dal ciclo di vita del software moderno.

In altri termini, a differenza di intervenire sull’intera applicazione, che tende oltretutto a divenire troppo complessa man mano che le funzioni aumentano e vanno aggiornate, l’architettura a microservizi consente ai team DevOps di operare agilmente in tutte le fasi, compresa quella relativa alla manutenzione, quando piccole modifiche renderebbero troppo lento e dispendioso l’intervento sull’intero monolite.

Continuous integration e continuous delivery (CI/CD)

Non esiste ovviamente un framework standard per quanto riguarda la CI/CD pipeline, in quanto sono i responsabili dei Team DevOps a scegliere le metodologie e i workflow più adatti a soddisfare le loro esigenze di sviluppo. Generalmente le fasi di una CI/CD pipeline sono essenzialmente quattro: source, build, test e deploy, concepite secondo un’ottica ciclica e continuativa.

Source

Durante il primo step, gli sviluppatori si preoccupano di scrivere unità di codice ragionevolmente piccole da distribuire, oltre a sottoporle a rapidi test che precedono la build vera e propria. I test su piccole unità di codice consentono di prevenire una serie di problemi, accelerando il ciclo di sviluppo.

Build

Il codice sorgente inizialmente predisposto viene caricato sul repository, collegato a librerie, moduli e dipendenze ed infine compilato in un file eseguibile. I tool utilizzati dai dev consentono di automatizzare questi step, registrando l’intero processo, indicando gli errori da correggere. Nello sviluppo delle applicazioni moderne, come nel caso del software cloud native, vengono utilizzati appositi ambienti di esecuzione, come le macchine virtuali o i container.

Test

Dopo la fase di build il codice è pronto per essere eseguito nei vari test sulle funzioni, sulle performance e sulla sicurezza, un particolare che non dovrebbe mai essere tralasciato, al punto che la metodologia DevOps, nella sua più recente evoluzione, è ormai riconosciuta come DevSecOps, integrando gli aspetti di sicurezza sin dalle fasi concettuali della progettazione.

I test, eseguibili su uno o più componenti dell’applicazione, servono a garantire che il codice sviluppato soddisfi gli standard di qualità previsti per l’utente finale e le specifiche del progetto. Le fasi di test sono eseguite mediante tool che consentono di automatizzare i vari step previsti.

Deploy

Dopo le fasi di build e test, il ciclo di sviluppo del software secondo la pipeline CI/CD prevede il momento del deploy, la distribuzione nel vero e proprio ambiente di produzione. Tra i metodi di deploy basati sul continuous delivery più comuni figura il cosiddetto blu/green, che prevede due ambienti configurati in maniera identica.

Il primo ambiente è quello che entra effettivamente in produzione per servire gli utenti finali, in maniera da garantire sempre la continuità del servizio, mentre un secondo prevede il test e il deploy di nuovo codice, come avviene generalmente nel caso dei test di carico per nuove funzioni. Se tali prove soddisfano tutti i parametri desiderati, il nuovo ambiente entra a tutti gli effetti in produzione e tutti gli utenti finali possono accedervi, in maniera assolutamente trasparente, senza notare alcuna situazione di “fermo” effettivo rispetto alla situazione precedente.

I vantaggi del continuous delivery

Rispetto allo sviluppo tradizionale, il continuous delivery, specie in combinazione con la continuous integration, offre moltissimi benefici, ma è possibile sintetizzarne tre per rendere perfettamente l’entità dei vantaggi che si prospettano.

Semplicità e rapidità per le nuove build

Il team DevOps impiega meno tempo a predisporre una base di codice per il deploy e non è più costretto a raggruppare singole modifiche prima di procedere con un unico aggiornamento collettivo, come avviene tuttora nel caso del software monolitico. Gli sviluppatori possono rispondere puntualmente alle esigenze degli utenti finali, aggiornando e rilasciando continuamente il codice in piccoli deploy incrementali.

Debugging più rapido

Lavorare su aggiornamenti piccoli e frequenti facilità notevolmente la scoperta dei bug nel nuovo codice. Ad esempio, se venisse rilevato un bug nel codice già distribuito nell'ambiente di produzione, gli sviluppatori potrebbero isolare soltanto la parte di codice inadeguata e provvedere rapidamente ad effettuare un aggiornamento incrementale. Questo consente al team DevOps di risolvere il problema effettivamente rilevato, testare il codice, ridistribuirlo e ricevere un nuovo feedback in tempi estremamente contenuti.

Ciclo di sviluppo del software più rapido

Il continuous delivery consente di fatto iterazioni più rapide delle applicazioni, in quanto consente a molti sviluppatori di collaborare e creare codice in momenti diversi senza interferire con gli altri progetti in corso. Tutto questo a favore della reversibilità degli interventi sul software. Se un processo iterativo diventasse difficile da gestire a causa della crescente complessità del progetto, il CD garantirebbe agli sviluppatori un modo per riprendere i microservizi precedentemente creati, per ridefinire versioni più piccole, affidabili e semplici da gestire. Il tutto logicamente senza dover riscrivere l’intera parte di applicazione da zero.