La continuous delivery, intesa sia come metodologia sia come tool, creato per sopperire alla crescente necessità di un rilascio rapido del software, ha guadagnato sempre più popolarità tra le aziende. Essendo in grado di mantenere il software in uno stato sempre pronto al rilascio, la continuous delivery si pone come evoluzione naturale della continuous integration e delle pratiche di sviluppo del software agile. Tuttavia le sfide culturali e operazionali che presenta il raggiungimento della continuous delivery sono molto più grandi. Secondo molte aziende la continuous delivery richiede l’adattamento e l’estensione dei processi di rilascio del software già esistenti. In questo processo possono essere inclusi anche i ruoli, i rapporti e le responsabilità delle persone all’interno dell’azienda. I tool utilizzati per il rilascio, l’aggiornamento e il mantenimento del software devono essere in grado di supportare in modo adeguato l’automazione e la collaborazione, per minimizzare i ritardi e permettere cicli di feedback ristretti all’interno dell’azienda.
Le aziende che valutano il passaggio alla continuous delivery dovrebbero tenere in considerazione i sette prerequisiti proposti qui di seguito, che permetteranno di operare con successo i cambiamenti culturali e operazionali, rispettando i limiti posti dal regolamento e dall’azienda.
I team di sviluppo, quality assurance e operation devono avere gli stessi obiettivi e comunicare
La continuous integration è un metodo che riguarda solo il team di sviluppo, la continuous delivery invece tocca le fasi di test del team di quality assurance (QA) e il rilascio all’ambiente di staging e produzione, gestiti dal team di operation in produzione. Nell’ambito dello sviluppo del software questa differenza è una grande novità. Per avere successo nella trasformazione della piattaforma di continuous integration in una di continuous delivery, integrando i team di QA e operation nella sua governance e coinvolgendo anche il team di sviluppo, si devono affrontare molte difficoltà. La collaborazione e la comunicazione sono componenti essenziali per uno sviluppo del software di successo e nella continuous delivery devono assumere un ruolo centrale.
La continuous integration deve essere già in uso per passare alla continuous delivery
La continuous delivery è un’estensione della continuous integration. Il prerequisito principale per passare alla continuous delivery è di aver già messo in uso la continuous integration durante il progetto, compresi la gestione di controllo del source code, le build automatizzate, unit tests e la continuous build del software.
Automatizzare e effettuare il controllo di versione su tutto
La continuous delivery comprende la ripetizione continua di molte operazioni quali la build di applicazioni e pacchetti, l’utilizzo di applicazioni e configurazioni e il reset di ambienti e database. Tutte queste operazioni, nella continuous delivery, devono essere automatizzate tramite tool e script e tenute sotto controllo di versione, in modo che tutto possa essere revisionato e riprodotto.
La condivisione di tool e procedure tra i team non è semplice
La continuous delivery permette di validare procedure di deploy e automatizzazione usate nell’ambiente di sviluppo. Per avere successo in questa operazione, queste procedure e automazioni devono essere usate prima possibile in modo che possano essere sottoposte a test in ogni loro parte quando vengono usate per rilasciare il software in produzione. In molti casi possono essere usati gli stessi tool in tutti gli ambienti, quali integrazione, staging e produzione.
Lo script per l’automazione dovrebbe essere gestito nel repository con il codice sorgente condiviso in modo che ogni team – sviluppo, QA e operation – possa migliorare tool e procedure. Meccanismi come le richieste di pull possono aiutare la governance di questi tool e script condivisi.
L’applicazione deve adattarsi alla produzione per rendere i deploy dei non-eventi
Le applicazioni devono semplificare le proprie procedure di deploy e rollback in modo che il deploy in produzione diventi un non-evento. Un passo ulteriore per raggiungere questo obiettivo è la riduzione del numero di componenti e di parametri di configurazione rilasciati. È importante rendere agevoli i rollback quando si rilasciano nuove versioni, permettendo così di tornare indietro facilmente in caso di problemi. I toggle delle funzionalità aiutano a dividere il deploy di binari dall’attivazione delle funzionalità, in questo modo un rollback può semplicemente essere la disattivazione di una funzione grazie ad un toggle.
Bisognerebbe prestare particolare attenzione ad ogni cambiamento di schema del database, poiché può rendere i deploy e i rollback molto più complessi. Il design del modello senza schema del database NoSQL permette molta flessibilità, portando la responsabilità dello schema dal database al codice. Questo concetto può anche essere applicato ai database relazionali.
L’infrastruttura deve adattarsi al progetto per dare importanza a team e persone
Le infrastrutture dovrebbero fornire tutti gli strumenti (GUI, API e SDK) e la documentazione necessaria per rendere autonomi i team di sviluppo e di QA. Questa operazione comprende:
Rilasciare la versione dell’applicazione scelta in un ambiente
Gestire la configurazione dei parametri (visualizzare, modificare, esportare, importare)
Gestire i database (creare la panoramica dei dati, ripristinare la panoramica di un database)
Permettere la visualizzazione, la ricerca e le notifiche nel registro delle applicazioni.
Le piattaforme cloud pubbliche, soprattutto Infrastrucure as a Service (IaaS) e Platform as a Service (PaaS), sono esempi di piattaforme adattate al progetto.
Le versioni dell’applicazione devono essere pronte a passare in produzione
Uno degli obiettivi principali della continuous delivery è permettere al proprietario del prodotto di decidere di rilasciare in produzione qualunque versione dell’applicazione che passa con successo attraverso la pipeline della continuous delivery, non solo la versione rilasciata alla fine di un’iterazione con un “buon” numero di versione.
Raggiungere questo obiettivo richiede diversi cambiamenti nella progettazione delle applicazioni:
Funzionalità che non sono ancora state convalidate dal team QA devono essere nascoste agli utenti finali. I toggle delle funzionalità e le branch delle funzionalità sono due modalità chiave per implementare questo passaggio.
Gli strumenti di build dovrebbero passare dal concetto di versioni semantiche separate da versioni di panoramiche intermedie e indefinite ad un flusso continuo di versioni non semantiche. Repository di sotto-versioni aiutano a mantenere ordinati i numeri di versione grazie ad un numero di revisione. Git, sistema di version control gratuito e open source, è più complesso da utilizzare proprio per le sue hash non ordinate, ma i altri strumenti specifici potrebbero servire a rendere questo identificatore di versione più “umanamente leggibile”.
Il punto è che la continuous delivery non è solamente un set di tool, ma coinvolge anche le persone e la cultura aziendale. La tecnologia, le persone e i processi devono allinearsi per rendere efficace la continuous delivery e l’approccio collaborativo è la chiave per ottenere questo successo. Implementare queste buone pratiche permette alle aziende di essere ricompensate da un approccio allo sviluppo del software più fluido e automatizzato, nonché agile.
