Il percorso di Driftrock verso la Continuous Delivery

Nell'ultimo anno, Driftrock ha intrapreso un percorso piuttosto comune – forse ne avete già sentito parlare – passando da distribuzioni manuali e una certa riluttanza a rilasciare il software a distribuzioni automatizzate e ripetibili, con l'obiettivo di fornire valore aggiunto.

Piuttosto che annoiarvi con l'ennesimo post sui vantaggi del Continuous Delivery, anche se mi piacerebbe farlo, cercherò invece di concentrarmi su come siamo riusciti a realizzare questo cambiamento. Ispirandomi al libro *More Fearless Change* di Mary Lynn Manns e Linda Rising, farò del mio meglio per ricordare i passi che abbiamo compiuto e, più in particolare, gli schemi che continuiamo a utilizzare per cercare di modificare i comportamenti del team.

Tornare indietro nel tempo

Per contestualizzare: nel giugno 2016, qualsiasi modifica apportata alle nostre applicazioni finiva per arrivare in produzione. Era molto difficile sapere se una modifica fosse stata effettivamente implementata; il modello di ramificazione in uso, purtroppo molto diffuso, aumentava notevolmente il carico cognitivo, e le implementazioni venivano avviate manualmente dal computer dello sviluppatore tramite la CLI di Heroku.

Un nuovo passaggio dall'ambiente di sviluppo a quello di produzione si presentava più o meno così:

Verde - fase automatizzata.
Arancione - fase manuale inevitabile o fase manuale che non intendiamo (ancora) modificare.
Rosso - fase manuale evitabile.

Inoltre, a seconda dell'applicazione, il processo di distribuzione presentava una serie di incongruenze. Alcune applicazioni non disponevano di un ambiente di staging; quelle che ne avevano uno potevano essere distribuite automaticamente in staging oppure no, e non tutte le applicazioni venivano sottoposte a test automatizzati sul ramo master o su altri rami. In breve, il processo era inutilmente complesso, estremamente incoerente e caratterizzato da un livello di automazione minimo o nullo. Non sorprende quindi che il team mostrasse scarso interesse quando si trattava di distribuire il software.

Tutto ciò comportava che le implementazioni fossero irregolari e rischiose. Il più delle volte veniva pubblicato un ampio lotto di modifiche, aumentando inevitabilmente la probabilità che qualcosa andasse storto e, in alcuni casi, rendendo impossibile un rollback in sicurezza.

Piccoli passi

Cercherò di illustrare le misure che abbiamo adottato e i modelli pertinenti che abbiamo utilizzato per migliorare lo scenario sopra descritto. In fondo a questa pagina è riportato un elenco dei modelli citati nel corso di questa guida. Inoltre, qui potete trovare tutti i modelli comodamente elencati e descritti.

Fase 1 - Coinvolgere tutti

In modo piuttosto insolito, tutto è iniziato con il miglioramento delle nostre retrospettive. Il team aveva bisogno di una piattaforma per discutere dei problemi e proporre miglioramenti (Coinvolgere tutti). Sebbene tenessimo una riunione settimanale chiamata "retrospettiva", questa aveva ben poco in comune con le retrospettive che avevo visto in diverse altre aziende. Inizialmente, questo incontro era molto più simile a un aggiornamento settimanale sullo stato di avanzamento dei lavori: si concentrava sulle attività quotidiane e sui loro progressi, piuttosto che sull'analisi di come migliorare il nostro modo di lavorare. Suggerire e poi dimostrare un approccio più strutturato alle retrospettive (facilitando le prime) ha avuto un impatto significativo sul team al di là del Continuous Delivery, ma uno dei primi punti di discussione riguardava il modo in cui distribuiamo il nostro software (Piantare i semi).

Fase 2 - Buttati!

Dato che il team era un po’ incerto sui vantaggi che il passaggio alla Continuous Delivery avrebbe potuto comportare, il passo successivo è stato semplice: mostrare loro un esempio (Just Do It). Ho messo insieme una semplice applicazione API HTTP con un unico endpoint che restituiva "200 OK" e ho creato una pipeline di distribuzione su Snap CI. Ho cercato di imitare il modo in cui gestiamo le nostre applicazioni standard e ho affrontato solo i problemi più immediati (Pick Your Battles): le distribuzioni manuali e la gestione di più rami durante la distribuzione. Quest'ultimo aspetto riduceva anche la distanza tra lo sviluppo locale e la produzione. Dimostrando che il nostro processo di distribuzione poteva iniziare a evolversi in questo:

Come ci si poteva aspettare (proprio come nel caso di un software funzionante), questo è diventato un ottimo punto di riferimento per mostrare e spiegare il valore del CD e come si differenzia da ciò che stavamo facendo.

Fase 3 - Prova generale

Una volta gettato il seme, grazie a un esempio concreto e alle difficoltà ricorrenti nel distribuire software di qualità (che ne evidenziavano solo la gravità – un vero e proprio campanello d’allarme), il coinvolgimento del resto del team è andato progressivamente aumentando. Il passo successivo è stato quello di coinvolgere il team nel trasferimento di una o due applicazioni reali sul nuovo sistema (fase di prova). Abbiamo preso due applicazioni problematiche per convalidare le nostre ipotesi il prima possibile, abbiamo creato delle pipeline di distribuzione per esse, le abbiamo distribuite con successo e abbiamo lasciato che il cambiamento si stabilizzasse. A questo punto, per fortuna, ho avuto un po' di aiuto (Chiedere aiuto), rendendo i progressi molto più rapidi e le potenziali reazioni negative più facili da gestire.

Fase 4 - Relazioni pubbliche costanti

Durante tutto questo processo, un tema citato nel libro mi ha particolarmente colpito: il "PR persistente". A ben vedere, questo concetto è emerso in modo sottile in diversi punti, a volte in modo intenzionale, ma spesso in modo involontario. Ecco una panoramica dei punti in cui è stato menzionato:

• Abbiamo modificato la nostra consueta riunione in piedi in modo che si concentrasse innanzitutto su ciò che è stato implementato in produzione, poi sullo staging e infine sullo sviluppo attivo — un approccio comunemente noto come "Walk the Board". Sebbene in modo indiretto, questo approccio serve a ricordare regolarmente al team l'importanza di concentrarsi innanzitutto sul rilascio del software e su come portare avanti le attività fino alla produzione.
• Durante una riunione aziendale settimanale abbiamo illustrato brevemente come abbiamo modificato il nostro approccio alla distribuzione del software. In realtà è successo per caso, ma è stata un'occasione da cogliere al volo (Segnali di successo).
• Abbiamo iniziato a raccogliere e comunicare i dati relativi al numero di implementazioni in produzione.
• Abbiamo introdotto alcuni circuiti di feedback per facilitare il flusso di informazioni relative alle implementazioni:
• Notifiche su Slack: invio di informazioni relative a build non riuscite o distribuzioni andate a buon fine. In questo modo, gli sviluppatori non dovevano più cercare lo stato delle loro modifiche: erano le notifiche a raggiungerli.
• Note di rilascio - Abbiamo iniziato ad annunciare internamente le modifiche destinate ai clienti man mano che venivano implementate. Questo ha contribuito a suscitare interesse e a stimolare il dibattito sulle nuove funzionalità tra i dipendenti di tutta l'azienda.
• Monitoraggio: è un aspetto che non abbiamo ancora definito del tutto, ma continuiamo a sperimentare diverse soluzioni di monitoraggio e modi più efficaci per raccogliere feedback dai nostri sistemi di produzione.

Allora, a che punto siamo?

Attualmente effettuiamo circa 15 distribuzioni in produzione a settimana, un ritmo sostenibile e adeguato alle dimensioni del nostro team. Abbiamo trasferito circa 30 progetti su Snap CI. Abbiamo creato pipeline di CD per una vasta gamma di applicazioni: gemme Ruby, pacchetti Elixir, siti statici ospitati su AWS, applicazioni web su Heroku e altre ospitate su Kubernetes. Ogni membro del team si assume la responsabilità di garantire che le modifiche su cui sta lavorando vengano implementate in produzione e lavora a stretto contatto con gli altri membri del team per testare le funzionalità pertinenti. Facciamo sempre più affidamento su test automatizzati, feature toggle e retrocompatibilità, argomenti che hanno avuto un ruolo di primo piano nelle nostre retrospettive.

Per inciso, Snap CI non ha soddisfatto appieno le nostre aspettative, ma anche questa esperienza ha portato alcuni aspetti positivi. Dopo aver riscontrato diversi problemi, abbiamo iniziato a puntare su Docker per la CI, con l’obiettivo di isolare e assumere il pieno controllo dell’ambiente di build. Ciò ha avuto numerose ricadute positive, come l’utilizzo di Docker in fase di sviluppo e il passaggio a Kubernetes. Inoltre, ha ridotto la nostra dipendenza dallo strumento CI/CD scelto, cosa che si è rivelata fondamentale quando Snap CI ha annunciato la sua chiusura. Fortunatamente, ora siamo in una posizione molto migliore per capire di cosa abbiamo bisogno, quindi stiamo passando a Buildkite(ne parleremo in un altro articolo!).

Speriamo che questo vi dia un'idea di come stiamo proseguendo la transizione verso la Continuous Delivery e dei modelli che ci hanno aiutato. Il nostro approccio continua ad evolversi man mano che impariamo e riconosciamo che abbiamo ancora molta strada da fare. Riassumere tutto questo impegno in quattro passaggi è certamente una semplificazione eccessiva: per arrivare dove siamo ora ci sono voluti molti mesi, anche per il nostro piccolo team. Questo percorso ci ha ricordato che un cambiamento come questo non avviene dall'oggi al domani e richiede molti piccoli passi, apparentemente insignificanti, nella giusta direzione.

Altre risorse utili

Linda Rising - Miti e modelli del cambiamento organizzativo
Continuous Delivery - Jez Humble & Dave Farley
Consegna continua - Da povero a ricco - Hibri Marzook
Sviluppo basato sul trunk

Riferimento ai modelli di modifica

Parafrasando leggermente il libro, ecco una selezione dei modelli che ho citato in precedenza:

Piccoli passi - Fai un piccolo passo alla volta verso il tuo obiettivo.
Coinvolgi tutti - Tutti dovrebbero avere l'opportunità di dare il proprio contributo.
Getta i semi - Cogli ogni occasione per suscitare interesse verso un'idea.
Fallo e basta - Non aspettare il momento perfetto, ma fai il primo piccolo passo e inizia a imparare.
Scegli le tue battaglie - Concentra i tuoi sforzi sulle questioni più urgenti.
Prova - Quando c'è riluttanza a impegnarsi in un'idea, suggerisci un esperimento per un breve periodo.
Segnale d'allarme - Sottolinea le questioni che rendono necessario un cambiamento.
Chiedi aiuto - Cerca persone e risorse che possano sostenere i tuoi sforzi e incoraggiano il coinvolgimento.
PR persistente - Mantieni la nuova idea sotto gli occhi di tutti, promuovila costantemente in vari modi.
Profumo di successo - Quando i tuoi sforzi producono un risultato positivo visibile, consideralo un'occasione di insegnamento.

‍