La Continuous Delivery, metodologia volta a soddisfare la crescente domanda di sviluppo software in cicli più brevi, assicurandone la qualità, è oggi un must aziendale.
Enfatizzando il mantenimento del software sempre pronto al rilascio, si configura come una naturale evoluzione della Continuous Integration e delle pratiche di sviluppo Agile del software. Tuttavia, le sfide culturali e operative per raggiungere una corretta implementazione della metodologia di Continuous Delivery sono maggiori.
Per la maggior parte delle aziende, l’adozione della Continuous Delivery significa adattare e estendere i processi di rilascio software già esistenti, prassi che da un lato impatta i ruoli, le relazioni e le responsabilità delle persone, dall’altra gli strumenti utilizzati per rilasciare, aggiornare e mantenere il software, che devono supportare correttamente l’automazione e la collaborazione, quindi minimizzare i ritardi e offrire rapidi cicli di risposta.
Chi desidera adottare l’approccio di Continuous Delivery deve tener conto di sette prerequisiti, ovvero sette step pratici che permettono di implementare con successo i cambiamenti culturali e operativi necessari, rispettando quei vincoli normativi e di business in cui le aziende operano.
Step 1: Development, Quality Assurance e Operations team devono condividere gli stessi obiettivi e devono comunicare tra loro
A differenza della Continuous Integration, che interessa solamente i team di sviluppo, la Continuous Delivery coinvolge sia le fasi di test gestite dai team di Quality Assurance (QA) sia le fasi di messa in produzione, gli ambienti di Staging (ambiente di preparazione alla pubblicazione) e di produzione, gestiti dagli Operations team. Si tratta di un grande cambiamento nello sviluppo del software. La criticità più grande del trasformare una piattaforma di Continuous Integration in una piattaforma di Continuous Delivery è rappresentata dalla corretta collaborazione tra QA e Operations nella sua governance, nonché il coinvolgimento del team di sviluppo. La collaborazione e la comunicazione sono oggi al centro di uno sviluppo software di successo; ancor di più in un ambiente di Continuous Delivery.
Step 2: La Continuous Integration deve funzionare correttamente prima di adottare la Continuous Delivery
La Continuous Delivery è un’estensione della Continuous Integration: presupposto per la Continuous Delivery è lo sviluppo di progetti preesistenti attraverso un corretto uso della Continuous Integration.
Step 3: Automatizzare e versionare tutto
La Continuous Delivery comporta la ripetizione continua di molte attività, come la creazione di applicazioni e pacchetti, la messa in produzione di applicazioni e configurazioni, l’azzeramento di ambienti e database. Nella Continuous Delivery tutti questi task vengono automatizzati attraverso tool e script e sottoposti a controllo di versione, in modo tale che ogni elemento possa essere verificato e riprodotto.
Step 4: La condivisione di strumenti e procedure tra team è fondamentale
La Continuous Delivery mira a validare le procedure di messa in produzione e automazione utilizzate nell’ambiente di produzione. Per poterlo fare in maniera eccelsa, queste procedure e queste automazioni devono essere adottate il prima possibile, in modo che siano ampiamente testate nel momento in cui vengono utilizzate per rilasciare il software alla produzione. Nella maggior parte dei casi, gli stessi strumenti possono essere utilizzati in tutti gli ambienti: integrazione, preparazione alla pubblicazione, produzione.
Gli script di automazione dovrebbero essere gestiti in repository di codice sorgente condivisi, cosicché ogni team (sviluppo, QA e team operativi) possa migliorare strumenti e procedure.
Step 5: L’applicazione deve essere compatibile e adatta alla produzione per rendere irrilevanti i deployments
Le applicazioni dovrebbero semplificare le procedure di deploy e rollback, per far sì che il deploy in produzione abbia un impatto minore.
Un importante passo per raggiungere questo obiettivo è ridurre il numero dei componenti e dei parametri di configurazione rilasciati. La facilità di rollback è importante per essere più veloci nella distribuzione di nuove versioni, potendo contare sulla possibilità di tornare facilmente indietro in caso di problemi.
Un’attenzione particolare dovrebbe essere prestata ad eventuali modifiche degli schemi di database, capaci di rendere le implementazioni e i rollback più complessi. Il modello di progettazione senza schema tipico dei database NoSQL conferisce molta flessibilità, spostando la responsabilità dello schema dal database al codice; concetto che può essere applicato anche ai database relazionali.
Step 6: L’infrastruttura deve essere orientata al progetto, per facilitare le persone e i team
Le infrastrutture dovrebbero fornire tutti gli strumenti (GUI, API e SDK) e la documentazione necessaria per favorire e rendere autonomi i team QA e di sviluppo.
In particolare nel:
• mettere in produzione la versione dell’applicazione scelta in un ambiente;
• gestire i parametri di configurazione (visualizzazione, modifica, export, import);
• gestire i database (creare snapshot di dati, ripristinare snapshot di database);
• consentire la visualizzazione, la ricerca e gli avvisi di notifica sui log delle applicazioni.
Esempi di piattaforme orientate al progetto sono le piattaforme cloud pubbliche, principalmente IaaS (Infrastructure as a Service) e PaaS (Platform as a Service).
Step 7: Le diverse versioni delle applicazioni devono essere pronte per essere mandate in produzione
Uno dei più importanti obiettivi della Continuous Delivery è consentire al proprietario di poter mettere in produzione qualsiasi versione dell’applicazione uscita dalla pipeline di Continuous Delivery, non solo la versione dal numero “importante”.
Il raggiungimento di questo obiettivo richiede molti cambiamenti nella progettazione delle applicazioni:
• Le funzionalità che non sono ancora validate dal team QA dovrebbero essere nascoste agli utenti finali. Usare le toggle e branch sono due modi per farlo.
• Gli strumenti di build dovrebbero permettere l’abbandono del concetto di versioni semantiche intervallate da versioni intermedie non identificate, per abbracciare il concetto di flusso continuo di versioni non semantiche. I repository Subversion contribuirebbero a fornire i numeri delle versioni ordinate grazie ad un numero di revisione, diversamente da Git, sistema di version control gratuito e Open Source, più complesso da usare per quest’operazione, per via degli hash del commit non ordinati, per cui uno specifico tool potrebbe essere necessario per rendere gli identificativi leggibili.
Risulta dunque evidente come la Continuous Delivery non sia semplicemente un insieme di strumenti, ma una metodologia che coinvolge le persone e la cultura aziendale e organizzativa. Una Continuous Delivery di successo presuppone l’allineamento di tecnologia, persone e processi interni nonché un approccio collaborativo. L’implementazione di queste sette best practices può consentire alle aziende di raccogliere i frutti di un approccio di sviluppo software automatizzato.
Vuoi saperne di più?
• Scarica il whitepaper: “Continuous Delivery per il rilascio dinamico di software di qualità”
Per maggiori informazioni contatta Emerasoft all’indirizzo mail sales@emerasoft.com o telefonicamente allo 0110120370 (sede di Torino) o allo 0687811323 (sede di Roma).
