Continuous delivery
Continuous delivery (CD) indica la pratica di utilizzare l'automazione per rilasciare software attraverso brevi iterazioni.
Cos'è la continuous delivery?
La continuous delivery è un approccio che consente ai team di rilasciare prodotti di qualità in modo frequente e prevedibile dal repository del codice sorgente all'ambiente di produzione sfruttando l'automazione.
Alcune organizzazioni rilasciano i prodotti manualmente trasferendoli da un team all'altro, come illustrato nel diagramma seguente. In genere, gli sviluppatori e il personale operativo si trovano alle estremità opposte della catena di operazioni. Questa situazione causa ritardi nelle consegne, con conseguente frustrazione dei team e insoddisfazione dei clienti. Il prodotto viene pubblicato soltanto al termine di un processo lungo e soggetto a errori che ritarda la generazione di profitto.
Figura 1: rilascio manuale dei prodotti ai clienti
Dai un'occhiata alla pipeline di continuous delivery qui sotto, che mostra come gli sviluppatori scrivono il codice sul proprio laptop ed eseguono il commit delle modifiche in un repository di codice sorgente, come Bitbucket. Per codice si intende il sistema in fase di test, i test e l'infrastruttura utilizzata per distribuire e gestire il sistema. Bitbucket Pipelines è in grado di rilasciare il prodotto dall'ambiente di test a quello di staging e fino in produzione, consentendo così ai clienti di usufruire delle nuove funzionalità in breve tempo.
Figura 2: pipeline di continuous delivery con rilasci automatici
Come funziona la continuous delivery?
La pipeline di continuous delivery può prevedere un controllo manuale subito prima della produzione. I controlli manuali richiedono l'intervento umano e potrebbero essere necessari nella pipeline per determinati scenari della tua organizzazione. Alcuni controlli manuali sono di dubbia utilità, altri invece rappresentano un valido strumento, ad esempio nei casi in cui il team aziendale deve prendere una decisione dell'ultimo minuto sul rilascio. Il team di progettazione tiene pronta una versione rilasciabile del prodotto dopo ogni sprint e il team aziendale decide se rilasciare il prodotto a tutti i clienti, a un campione di destinatari o a persone che vivono in una determinata località geografica.
L'architettura del prodotto che passa attraverso la pipeline è un fattore chiave per determinare l'anatomia della pipeline di continuous delivery. Un'architettura di prodotto fortemente accoppiata genera un modello grafico complesso in cui diverse pipeline si ostacolano a vicenda prima di arrivare in produzione.
L'architettura di prodotto influenza anche le diverse fasi della pipeline e gli artefatti prodotti in ciascuna fase. La pipeline crea innanzitutto i componenti, ossia le unità distribuibili e testabili più piccole del prodotto. Ad esempio, una raccolta creata dalla pipeline può essere definita un componente. Questa è la fase Componente.
I componenti debolmente accoppiati costituiscono i sottosistemi, ossia le unità distribuibili ed eseguibili più piccole. Alcuni esempi di sottosistemi sono i server e i microservizi in esecuzione in un container. Questa fase si definisce Sottosistema. A differenza dei componenti, i sottosistemi possono essere valutati durante uno stand-up e testati.
Pertanto, è possibile insegnare alla pipeline ad assemblare un sistema partendo da sottosistemi debolmente accoppiati nei casi in cui un sistema debba essere rilasciato nella sua interezza. Questa è la fase Sistema.
Sconsigliamo di assemblare i sottosistemi in un sistema. Questo tipo di composizione è illustrato nella Figura 3.
Figura 3: sottosistemi assemblati in un sistema
Questo approccio radicale fa sì che il sottosistema più veloce si adegui alla velocità di quello più lento. "La catena è forte quanto il suo anello più debole" è un luogo comune che utilizziamo per mettere in guardia i team che cadono vittime di questo modello di architettura.
Una volta convalidato, il sistema assemblato viene quindi trasferito all'ambiente di produzione senza ulteriori modifiche: è la fase finale, chiamata Produzione.
Ricordati che si tratta di fasi più logiche che fisiche, create al solo scopo di scomporre un problema complesso in parti più piccole e più gestibili. Il numero di fasi può aumentare o diminuire, a seconda della tua architettura e dei tuoi requisiti.
Velocità e qualità devono andare di pari passo per i nostri clienti. Il test continuo è una tecnica in base alla quale i test automatizzati sono integrati nella pipeline di distribuzione del software e convalidano ogni modifica all'interno della stessa. I test vengono eseguiti in ogni fase della pipeline per convalidare gli artefatti prodotti in quella fase. I test unitari e l'analisi del codice statico convalidano i componenti nella fase Componente della pipeline, mentre i test funzionali, delle prestazioni e di sicurezza convalidano i sottosistemi nella fase Sottosistema. I test di integrazione, prestazioni e sicurezza convalidano i sistemi nella fase Sistema; infine, gli smoke test convalidano il prodotto nella fase Produzione.
Test automatizzati integrabili nella pipeline
Un prodotto con un'architettura monolitica, ossia un sistema costruito in modo caotico, può comportare una quantità esorbitante di test. Consigliamo di investire nei microservizi affinché gli artefatti distribuibili in modo indipendente possano passare attraverso le pipeline senza bisogno di un ambiente altamente integrato per la certificazione. Inoltre, questo tipo di artefatti consente ai team più rapidi di non farsi bloccare dai team più lenti.
Valore della continuous delivery
La pipeline di distribuzione del software è un prodotto a sé stante e dovrebbe essere una priorità per le aziende. In caso contrario, sconsigliamo di inviare alla pipeline prodotti che generano entrate. La continuous delivery aggiunge valore in tre modi: migliora la velocity, la produttività e la sostenibilità dei team di sviluppo software.
Velocity
Il termine velocity indica una velocità scelta in modo responsabile e non controproducente. Le pipeline sono pensate per rilasciare prodotti di qualità ai clienti. Se i team non prestano la dovuta attenzione, le pipeline possono inviare codice errato in produzione più rapidamente del dovuto. Le pipeline automatizzate di distribuzione del software aiutano le organizzazioni a rispondere meglio ai cambiamenti del mercato.
Produttività
Quando le pipeline eseguono attività lunghe, come l'invio di una richiesta per ciascuna modifica che passa in produzione, al posto degli esseri umani si verifica un picco di produttività. I team Scrum possono quindi concentrarsi sulla qualità dei prodotti invece di sprecare energie per la logistica. Il risultato? Membri del team più felici e più coinvolti nel lavoro, e desiderosi di contribuire a lungo al successo della squadra.
Sostenibilità
La sostenibilità è fondamentale per tutte le aziende, non solo per quelle del settore tecnologico. L'affermazione "Il software sta divorando il mondo" è ormai superata: il software ha già inglobato il mondo. Che si tratti di sanità, finanza, vendita al dettaglio o altri settori, le aziende sfruttano la tecnologia per distinguersi dalla concorrenza e surclassare i competitor. L'automazione aiuta a ridurre e a eliminare i ripetitivi task manuali, soggetti a errori, mettendo così l'azienda nelle condizioni ideali per innovare meglio, più rapidamente, e soddisfare le esigenze dei propri clienti.
Chi dovrebbe adottare la continuous delivery e quando?
Qual è il momento giusto per adottare la continuous delivery? Era ieri.
I team necessitano di un unico backlog ordinato per priorità dove:
- La continuous delivery è stata pienamente adottata, invece di essere relegata in secondo piano
- I criteri di accettazione delle storie utenti menzionano esplicitamente gli approcci di distribuzione automatizzata del software anziché quelli manuali
- Lo sprint "Definizione di 'Completato'" impedisce ai team di terminare gli sprint in cui il prodotto è stato rilasciato manualmente
La continuous delivery è la scelta migliore e a volte richiede il sostegno degli esperti per accelerare la trasformazione. Se le pipeline di continuous delivery sono progettate nel modo giusto, l'investimento si ammortizza facilmente.
E quindi, chi sono le figure coinvolte?
Alcune organizzazioni affidano a persone inesperte la progettazione e l'implementazione di pipeline di continuous delivery e scoprono a proprie spese la profonda complessità del processo. La scelta di membri junior invia un segnale sbagliato ai team e implica che la continuous delivery ha una bassa priorità. Consigliamo vivamente di affidare il progetto a un senior architect appassionato di operazioni di business e attività tecnologiche.
Oltre la continuous delivery
A prescindere dal punto in cui si trova la tua azienda, l’adozione di un approccio continuo per ogni fase, dall'integrazione al test, dalla consegna alla distribuzione, fino all'analisi e così via, non consiste in un elenco di attività da completare o in una meta da raggiungere, ma di un percorso al centro del quale si trova il miglioramento continuo.
Prima o poi, tutti i membri dell'organizzazione vengono coinvolti nella creazione di pipeline di continuous delivery: dirigenti, ingegneri e responsabili di prodotto, business unit di governance, rischio, conformità, InfoSec, attività operative e legali e molto altro ancora. Le pipeline abbattono i silos e le barriere. Tutti noi facciamo parte di questa trasformazione, in un modo o nell'altro: il concetto di "continuo" rappresenta la nuova normalità.
Introduzione a CI/CD
Per iniziare a implementare CI/CD puoi utilizzare strumenti specifici che aiutano con l'integrazione e automatizzano i processi di sviluppo, distribuzione e test .
Atlassian offre una soluzione Open DevOps che fornisce processi DevOps end-to-end, tra cui CI/CD. I team possono utilizzare numerosi strumenti come Bitbucket Pipelines, un servizio di CI/CD integrato in Bitbucket che consente di compilare, testare e persino distribuire automaticamente il codice in base al file di configurazione presente nel repository. Open DevOps può essere integrato anche con altri strumenti di CI/CD tra cui Harness, GitLab, JFrog, Codefresh e CircleCi.
Ecco un'analisi dettagliata delle integrazioni Open DevOps. Ricordati di dare un'occhiata ai nostri tutorial su CI/CD DevOps.
Iscriviti per ricevere altri articoli e tutorial su CI/CD e DevOps
