Lo sviluppo software con modifiche frequenti alle applicazioni tipico della Continuous Integration (CI) servirebbe in sé a poco, se non fosse immediatamente seguito da un approccio altrettanto iterativo alla implementazione del nuovo codice. Si tratta della cosiddetta Continuous Delivery (CD), talmente connessa alla CI da fare in effetti parte di un binomio CI/CD oggi inscindibile.

Se ragioniamo in ottica DevOps, la Continuous Delivery è la più legata alla parte Ops e può essere considerata come il ponte tra lo sviluppo e le operations. Entra infatti in azione quando un insieme di modifiche al codice è stato completato ed accettato da tutto il team di sviluppo, ed è quindi il momento di implementarle negli ambienti di produzione.

Come per la CI, anche nel caso della Continuous Delivery uno dei vantaggi principali dell'approccio "continuo" sta nell'automazione delle procedure, in modo da ridurre al minimo la possibilità di errori o cattive configurazioni. La delivery delle applicazioni o dei servizi modificati si attiva automaticamente a seconda degli eventi che si è deciso di considerare come scatenanti, di solito i commit del codice in ambienti come GitHub o il lasso di tempo trascorso dall'ultimo aggiornamento in produzione.

Continuous Delivery vuol dire anche test

È importante considerare che nella Continuous Delivery rientra anche la parte principale delle attività di test automatizzato sul buon funzionamento e sulle prestazioni delle applicazioni e dei servizi, modificati nella precedente Continuous Integration. La CI comprende sì una sua parte di testing, ma questa viene demandata ai singoli sviluppatori e tocca quindi in modo separato le varie modifiche che ciascuno apporta.

Le attività di test che rientrano nella Continuous Delivery coprono invece il funzionamento di una applicazione o di un servizio nel suo complesso, in particolare per quanto riguarda gli aspetti di sicurezza e anche - elemento essenziale negli ambienti a microservizi - il buon funzionamento del dialogo via API.

Un elemento essenziale nella parte di test è che questa deve essere il più possibile standardizzata, oltre che automatizzata. Chi si occupa di assicurazione qualità per il software deve poter definire quali tipi di test devono essere eseguiti per quali tipi di applicazioni/servizi e, soprattutto, quali di questi test devono essere necessariamente superati per poter considerare funzionale una nuova versione del codice.

I passi della Continuous Delivery

Operativamente la Continuous Delivery è affidata a piattaforme estese che coprono anche la parte di CI, come in primo luogo Jenkins. Per la parte di CD questi tool seguono una sequenza di passi automatizzati e standardizzati. Si possono adottare diverse best practice ma non esiste "la" pipeline di Continuous Delivery. Ogni azienda può definire la sua (o le sue), mettendo insieme le esigenze dei team di sviluppo e di quelli di operations.


In linea di massima, un tool di Continuous Delivery esegue almeno i seguenti passi.
- Attiva le risorse IT richieste dalla implementazione della nuova versione di una applicazione (o servizio).
- Configura queste risorse (e riconfigura quelle eventualmente già attive) in funzione delle esigenze dell'applicazione stessa.
- Si assicura di poter ripristinare i sistemi a una configurazione stabile se la nuova applicazione non dovesse funzionare correttamente.
- Implementa concretamente i nuovi componenti applicativi.
- Riavvia i moduli e i servizi che hanno bisogno di un "refresh" per adattarsi alla nuova configurazione dell'infrastruttura IT.
- Esegue i test automatizzati previsti.
- Se l'applicazione fallisce questi test, ripristina i sistemi a una configurazione stabile.
- Permette agli altri sistemi e allo staff IT di osservare tutto quello che è successo.

Come accennato, è importante che la pipeline di Continuous Delivery venga standardizzata in accordo tra team di sviluppo e team operations, perché questa standardizzazione delle procedure è una garanzia per entrambi. Gli sviluppatori sanno di poter modificare frequentemente le applicazioni senza problemi, mentre le operations sanno che sono in atto procedure automatiche che garantiscono la stabilità dei sistemi.

Dato che in generale velocità e stabilità non vanno d'accordo quando si tratta di IT, il vantaggio di una piattaforma di CI/CD è evidente. Questo non vuol dire eliminare del tutto gli attriti tra sviluppo e operations: serve comunque che le due parti arrivino a un accordo non sempre semplice su tutto il flusso Continuous Integration / Continuous Delivery. Una volta raggiunto questo accordo, però, standardizzazione e automazione garantiscono che questo sia rispettato sempre in maniera coerente.