Principi e pratiche di Continuous Delivery

Ogni sviluppatore ha provato, almeno una volta nella vita, quella sensazione di tensione che accompagna il Delivery Day. Conoscendo le insidie dello sviluppo di un software, si teme che nel momento in cui questo comincerà ad essere utilizzato emergeranno difetti, incongruenze e malfunzionamenti.

Ma siamo davvero sicuri che debba necessariamente essere così? Si può superare il timore del rilascio trasformando ogni giorno in un D-day? Sì, attraverso la pratica del Continuous Delivery.

Are you a release candidate?

A differenza dei processi tradizionali, in cui la fase di sviluppo prodotto è separata dalle attività funzionali al rilascio del software, il Continuous Delivery si propone di realizzare software sempre pronto per essere rilasciato.

In che modo? Attraverso l’integrazione continua di ogni singolo sviluppo, rilasciato in un ambiente di staging, analogo a quello di produzione. Il software che arriva a questa fase ha già superato le fasi di build e test, e di fatto è già in condizione di poter essere rilasciato. Ogni cambiamento introdotto nel sistema seguendo questa prassi è quindi un release candidate, rilasciabile in produzione come una nuova versione del software.

Questo processo può essere portato al suo estremo, automatizzando quest’ultimo passaggio ed eliminando l’approvazione dell’essere umano alla messa in produzione: si tratta della pratica di Continuous Deployment.

Differenze tra diversi modelli di rilascio

I principi del Continuous Delivery

A partire dalla concezione di release candidate, è possibile individuare i sei principi essenziali per garantire un processo di rilascio efficace e continuo.

• Automatizzare il più possibile: è il prerequisito per una pipeline di deployment affidabile, ripetibile e semplice.
• Mantenere tutto in controllo versione: ogni changeset deve essere referenziato con un numero di versione e deve essere sempre possibile identificare quale build dei vari applicativi è rilasciata in un dato momento in ogni singolo ambiente, e da quale versione proviene.
• Costruire sulla qualità: integration, test e release vanno anticipati il più possibile per poter individuare immediatamente i difetti del software e intervenire per correggerli. In questo modo, è possibile arrivare al Build Quality In.
• “Finito” vuol dire “rilasciato”: una feature raggiunge il suo scopo solo nel momento in cui viene utilizzata dai suoi utenti; in un processo di CD si considera finito solo ciò che è già stato rilasciato.
• Ognuno è responsabile: è fondamentale rendere le persone del team corresponsabili e incoraggiare la collaborazione per ottenere rilasci rapidi e affidabili. Il successo di un progetto è sempre un successo di team.
• Miglioramento continuo: il processo di rilascio deve essere continuamente e incrementalmente migliorato, esattamente come per un’applicazione.

Un processo anche per le piccole realtà

La metodologia di CD è celebre per essere utilizzata nelle più grandi aziende del mondo digitale come Google, Yahoo, Amazon e Facebook per citarne qualcuna. Ma la sua funzionalità non è legata alle dimensioni aziendali: si tratta di un insieme di principi che possono essere efficacemente applicati a qualsiasi dimensione aziendale.

La nostra esperienza

La nostra esperienza in tema di Continuous Delivery è nata dalla necessità di conciliare i rilasci di prodotto con gli sviluppi, gli aggiornamenti e la manutenzione degli applicativi dei clienti, ciascuno dei quali ha tempistiche ed esigenze proprie.

Tre anni fa uno dei nostri Team ha deciso di introdurre nel proprio percorso di rilascio alcuni principi di Continuous Delivery, trasformandoli in applicazioni pratiche adoperabili nel proprio contesto; dato il loro successo, oggi questi principi sono diventati un caposaldo dello sviluppo in Mia‑Platform. Guardiamoli insieme:

• Obiettivi pianificati: creare una board di team per tenere sotto controllo gli obiettivi di rilascio stabiliti per ogni ciclo di lavoro, con periodicità definita (tipicamente settimanale), secondo una metodologia Agile.
• Pipeline di deployment automatica: il codice sviluppato e versionato attiva una pipeline automatica di build, unit test e test di accettazione. Il rilascio in ambiente di staging è abilitato dal Product Owner, interno al team, che ne verifica i requisiti di accettazione. Nel corso di ogni sprint le feature pronte passano in produzione tramite un deployment automatico, azionato manualmente durante le finestre di rilascio prestabilite.

La pipeline del team che porta il codice dal checkout all’ambiente di staging (NB: per questo team, la linea rossa indica uno step attivato manualmente).

• Finestre di rilascio: a seconda del dominio applicativo e analizzando il traffico degli utenti è possibile individuare le finestre temporali più adatte per i rilasci, a seconda delle esigenze. A seconda del cliente, infatti, non è sempre possibile rilasciare qualsiasi software in qualsiasi momento. In queste finestre temporali dunque deve essere previsto anche il tempo per eventuali rollback, il re-deployment della precedente versione.
• Small batches: la complessità di merge aumenta esponenzialmente al crescere della quantità di codice rilasciato. Quindi, suddividere il lavoro in singole feature e procedere per cicli di sviluppo incrementali diminuisce la probabilità di fallire il rilascio. Inoltre, un eventuale roll-back non invaliderebbe tutto il lavoro fatto.
• Versionamento rigoroso: quando i rilasci in tutti gli ambienti sono frequenti è fondamentale sapere sempre che cosa è stato rilasciato in ogni ambiente; per questo, ogni applicazione e servizio espone il proprio numero di versione. In questo modo, i team possono incrementare il numero dei propri rilasci e le rotture critiche sono pressoché inesistenti, poiché i cambiamenti che rompono il sistema vengono automaticamente bloccati prima che arrivino in produzione.

In conclusione

I principi di Continuous Delivery, applicati al contesto di sviluppo di ciascun team, permettono di affrontare e superare la paura del rilascio, facendo evolvere il software in modo più rapido, semplice e affidabile.

Secondo la nostra esperienza, un buon processo di delivery deve essere automatico, attivabile da qualsiasi membro del team, uguale per tutti gli ambienti e deve prevedere momenti di build e deploy separati. Inoltre, deve seguire un sistema di versionamento rigoroso e garantire in modo continuo il rollback del software.

Questo articolo proviene da un talk di Riccardo Porrini e Tommaso Ballardini ed è stato pubblicato in forma originale su Mokabyte nel numero di Maggio 2019.