Nella procedura di sviluppo software, la continuous delivery permette di lavorare in modo snello ed efficiente. Ecco cosa c’è da sapere su caratteristiche e vantaggi
Nel mondo dello sviluppo software la continuous delivery ha un ruolo essenziale. Questo approccio per produrre software in cicli brevi garantisce che il prodotto possa essere rilasciato in modo affidabile in tempi rapidi.
Come vedremo, continuous delivery è parte di una pipeline, di cui fa parte anche la continuous integration (CI) il cui principale vantaggio risiede nell’automazione dell’intero ciclo di vita dell’applicazione.
Continuous delivery è una diretta conseguenza di un modo di intendere, nel mondo dello sviluppo software, che ha le sue radici agli inizi degli anni Duemila, quando un gruppo di sviluppatori ha creato un nuovo approccio allo sviluppo tecnologico. Chiamato Agile, il processo ha messo i clienti al centro dello sviluppo del prodotto, ha incoraggiato la prototipazione rapida e ha aumentato notevolmente la velocità e l’agilità aziendale. Come mette bene in luce un articolo pubblicato sull’Harvard Business Review, sebbene Agile sia stato concepito come innovazione nello sviluppo del prodotto, ha innescato una strategia aziendale e una rivoluzione dei processi basati su una metodologia mirata allo sviluppo continuo. Invece di migliorare il software in un unico grande lotto, gli aggiornamenti vengono effettuati in modo continuo, rapido, consentendo di consegnare il codice software ai clienti non appena viene completato e testato. In questo modo di intendere si è affermata la continuous delivery.
Per comprendere la portata del suo avvento è illuminante l’esempio di Facebook (oggi Meta). Quando è stata fondata nel 2004, la società ha adottato la metodologia agile di distribuzione del software per garantire che il codice venisse spedito il più rapidamente possibile. L’organizzazione si è evoluta in un ciclo di rilascio settimanale, rispondendo rapidamente al mercato e alla concorrenza. Ma nel 2016, il team di ingegneri ha faticato a supportare la portata dei rilasci settimanali, che comportavano da ottomila a 14mila modifiche software e richiedevano fino a 14 ore per l’implementazione in produzione. Nel 2017, Facebook è passato a un modello di continuous delivery. Così la richiesta di tempo necessaria per l’implementazione in produzione del codice di un ingegnere è passata mediamente a sole 3 ore e mezzo, passando a 2 ore l’anno successivo.
Cos’è la continuous delivery, come funziona e la pipeline CI/CD
La continuous delivery è un approccio alla distribuzione del software in cui i team di sviluppo producono e testano il codice in cicli brevi ma continui, solitamente con elevati livelli di automazione, per migliorare la qualità del software. Questo processo consente ai team di sviluppo di creare, testare e distribuire rapidamente il software, incoraggiando a fare aggiornamenti in modo incrementale, anziché dedicare troppo tempo a una revisione completa di un determinato prodotto.
Continuous delivery è un approccio diffuso per la distribuzione del software, soprattutto per i team che hanno pratica di DevOps. Solitamente viene abbinata alla continuous integration (CI) per formare una catena di processi per lo sviluppo, distribuzione e cicli di feedback del software chiamata pipeline CI/CD. Quest’ultima prevede una serie di passaggi da eseguirsi per fornire una nuova versione del software: l’abbinamento di CI con CD garantisce che il codice su cui hanno lavorato più sviluppatori provenienti da più posizioni sia integrato in un unico repository.
CI/CD incarnano una cultura, principi operativi e un insieme di pratiche che i team di sviluppo delle applicazioni utilizzano per fornire modifiche al codice con maggiore frequenza e affidabilità.
L’integrazione continua, spiega NIST, è una filosofia di codifica e un insieme di pratiche che spingono i team di sviluppo a implementare frequentemente piccole modifiche al codice e ad archiviarle in un repository di controllo della versione. La maggior parte delle applicazioni moderne richiede lo sviluppo di codice utilizzando una varietà di piattaforme e strumenti, quindi i team necessitano di un meccanismo coerente per integrare e convalidare le modifiche. L’integrazione continua stabilisce un modo automatizzato per creare, creare pacchetti e testare le proprie applicazioni. Contare su un processo di integrazione coerente incoraggia gli sviluppatori ad apportare modifiche al codice con maggiore frequenza, comportando una migliore collaborazione e una migliore qualità del codice.
Continuous delivery riprende dove termina l’integrazione continua e automatizza la distribuzione delle applicazioni in ambienti selezionati, inclusi ambienti di produzione, sviluppo e test. La distribuzione continua è un modo automatizzato per inviare modifiche al codice in questi ambienti.
Caratteristiche e vantaggi della continuous delivery
In un ambiente di produzione, la continuous delivery implica la designazione di una frequenza di rilascio in base alla natura del software o al mercato in cui opera l’organizzazione. Ciò significa che oltre ai test automatizzati, esiste un processo di rilascio pianificato, sebbene l’applicazione possa essere distribuita in qualsiasi momento. Il processo di distribuzione in continuous delivery è caratterizzato come manuale, ma attività come la migrazione del codice su un server di produzione, la definizione dei parametri di rete e la specifica dei dati di configurazione del runtime possono essere eseguite tramite script automatizzati.
Grazie alle caratteristiche ottenibili con CD si possono ottenere diversi vantaggi. Innanzitutto è possibile contare su rilasci a basso rischio. L’obiettivo principale della distribuzione continua è rendere la distribuzione di software indolori e con eventi a basso rischio che possano essere eseguiti in qualsiasi momento, su richiesta. Un altro beneficio ottenibile è un time-to-market più rapido. Non è raro che la fase di integrazione e test/correzione del tradizionale ciclo di vita di distribuzione graduale del software richieda settimane o addirittura mesi. Quando i team lavorano insieme per automatizzare i processi di creazione e distribuzione, provisioning dell’ambiente e test di regressione, gli sviluppatori possono incorporare test di integrazione e regressione nel loro lavoro quotidiano ed eliminare completamente queste fasi, snellendo le varie procedure.
Una volta che gli sviluppatori dispongono di strumenti automatizzati in grado di rilevare regressioni in pochi minuti, i team sono liberi di concentrare i propri sforzi sulla ricerca degli utenti e su attività di test di livello superiore come test esplorativi, test di usabilità e test di prestazioni e sicurezza, aumentando la qualità dei prodotti. Costruendo una pipeline CI/CD, queste attività possono essere eseguite in modo continuo durante tutto il processo di distribuzione, garantendo che la qualità sia integrata nei prodotti e nei servizi fin dall’inizio.
A ciò si aggiunge un altro, considerevole pregio: i costi inferiori. Investendo in creazione, test, distribuzione e automazione dell’ambiente si possono ridurre significativamente i costi di realizzazione e fornitura di modifiche incrementali al software eliminando molti dei costi fissi associati al processo di rilascio.
A tutto questo si aggiunge che la continuous delivery è comunemente utilizzata nel paradigma DevOps, pensato per essere un approccio collaborativo alle attività eseguite dai team di sviluppo delle applicazioni e delle operazioni IT, spesso con un’enfasi sull’automazione. Gli obiettivi di DevOps e di distribuzione continua si allineano per consentire un framework continuo. Le organizzazioni DevOps grandi e piccole utilizzano la distribuzione continua per ottenere vantaggi quali uno sviluppo software, processi di rilascio e commit del codice più rapidi e di qualità superiore.
Chi dovrebbe adottarla
Continuous delivery, come detto, è utilizzato nello sviluppo di software, la cui procedura di rilascio può essere un processo complesso e dispendioso in termini di tempo. Un processo che richiede settimane di integrazione manuale, configurazione e test, mentre il rischio sempre presente di scoprire un ostacolo minaccia di costringere tutti a tornare al punto di partenza. L’impegno di tempo necessario per preparare il codice per il rilascio può significare che le modifiche vengono apportate nella migliore delle ipotesi ogni pochi mesi. Ma c’è un altro modo.
La pipeline CI/CD, di cui continuous delivery è parte integrante, ha consentito a molte organizzazioni di effettuare rilasci con maggiore frequenza senza compromettere la qualità. Con essa, le modifiche al codice vengono gestite attraverso una pipeline automatizzata che gestisce le attività ripetitive di creazione, test e distribuzione e ti avvisa di eventuali problemi.
Quindi, rispondendo alla domanda su chi dovrebbe adottare la continuous delivery è naturale dire i team di sviluppo software, specie quelli che – sempre più numerosi – hanno necessità di adottare procedure rapide per rilasciare applicazioni.
Continuous delivery vs continuous deployment
Continuous delivery e continuous deployment hanno affinità e differenze. Intanto entrambi trovano impiego insieme all’integrazione continua, motivo per cui anche il termine CI/CD può essere abbinato a entrambi. A seconda del flusso di lavoro e dei requisiti esistenti, i team di sviluppo sceglieranno la pratica più adatta loro e al prodotto che stanno realizzando.
La differenza fondamentale tra i due CD riguarda ciò che accade durante il processo di distribuzione. Nella continuous delivery il codice scorre automaticamente attraverso più passaggi per prepararlo per la distribuzione in produzione, ma non viene pubblicato automaticamente. Le modifiche al codice devono prima essere approvate manualmente ed è probabile che siano necessari test manuali e garanzia di qualità. Invece, nel continuous deployment il codice può essere automaticamente testato, controllato e rilasciato in un ambiente di produzione, dove viene adattato in modo automatico alla domanda degli utenti e monitorato per eventuali problemi che richiederebbero un ripristino.
