Fare deploy in produzione a ogni modifica può fare paura, ma non fare deploy direttamente in produzione fa ancora più paura.
Questo è il processo che ho gestito in Amazon, guidando un team che distribuiva a centinaia di milioni di clienti. Attraverso la mia attività di consulenza, ho accompagnato team di ingegneri dal rilascio pianificato ogni due settimane al deploy a ogni merge.
Partiamo dall'ovvio:
Provocherai un'interruzione del servizio. Non è un se, ma un quando.
Nessuna quantità di unit test, test di integrazione, dogfooding, test end-to-end o qualunque altra cosa, o sacrifici agli dei del deploy, riuscirà a catturare ogni bug.
I test fatti sulla tua funzionalità una settimana fa non sono stati eseguiti insieme alle ultime modifiche del tuo collega.
I tuoi test sono stati eseguiti contro la versione pre-produzione del servizio del tuo collega, che ora è cambiata e contiene una modifica non retrocompatibile.
Più aspetti, più modifiche si accumulano in un rilascio. Se devi fare rollback, devi annullare due settimane di modifiche invece di 1-2 ore di lavoro.
Se accettiamo il presupposto che un'interruzione sia inevitabile, ha molto meno senso dedicare enormi risorse al QA di un rilascio. È meglio concentrare le risorse sul monitoraggio e sull'osservazione del rilascio ed essere pronti a gestire l'interruzione quando si verifica.
Ora vediamo come arrivarci:
Prerequisiti:
CI/CD
I test contano molto meno di quanto pensi. I test non possono dimostrare che la tua modifica sia sicura in produzione. Niente può farlo. Quello che fanno i test è rendere il fallimento economico. Un bug scoperto in CI costa minuti. Un bug scoperto in produzione ti costa la serata per fare un rollback.
Quindi esegui l'intera suite a ogni merge, o almeno come parte della pipeline: test unitari, di integrazione, end-to-end. Più il bug viaggia lungo la pipeline, più costa risolverlo.
Monitoraggio/Osservabilità
L'obiettivo del gioco è riuscire a individuare una regressione il prima possibile. Per farlo, serve un monitoraggio eccellente, che si articola in:
- metriche: errori, latenza, disponibilità
- log con ID di correlazione
- allarmi per sev-3 e sev-2 (paging) collegati ai due punti precedenti
Calibrare le soglie degli allarmi è insieme un'arte e una scienza. È un equilibrio tra sensibilità e velocità di risposta a un incidente reale. Il tempo target di alert per un sev-2 dovrebbe essere di 5-10 minuti.
All'inizio è probabile che sbagli e che gli allarmi siano troppo sensibili. Purtroppo, è una cosa che si impara soprattutto per tentativi ed errori, quindi preparati a qualche risveglio alle 2 di notte.
Feature Flag
Per qualsiasi modifica rischiosa, dovresti distribuirla dietro un feature flag / remote config. Un feature flag ti permette di disattivare e annullare qualsiasi modifica in pochi minuti, invece di dover fare rollback dell'intero deployment. Inoltre, se il tuo servizio di feature flag lo consente (e dovrebbe), puoi distribuire la funzionalità in modo incrementale in base a una percentuale o a una coorte, riducendo ulteriormente l'impatto di una modifica problematica.
Questo ci permette di disaccoppiare il deploy del codice dall'attivazione del codice. È un dettaglio sottile, ma cambia le regole del gioco per ridurre il rischio.
Nota: ti servirà un processo per ripulire i flag. Idealmente, crea un ticket di rimozione per ogni flag creato. Altrimenti, quando il tuo servizio di feature flag andrà giù (e succederà), avrai una regressione significativa. Chiedimi come lo so.
Rollback Automatico (circuit breaker al momento del deploy)
Un circuit breaker al momento del deploy è una funzionalità che consente di annullare il deployment se noti un numero o una percentuale di errori mentre lo stai distribuendo sul parco macchine. La maggior parte dei provider cloud oggi lo offre con una semplice casella da spuntare.
Modifiche Retrocompatibili
Dovresti già farlo, ma il deploy a ogni commit impone questa pratica. Durante un deployment progressivo, avrai la versione vecchia e quella nuova in esecuzione contemporaneamente. Ogni modifica deve funzionare insieme alla versione precedente. Il tuo trucco di fare deploy a mezzanotte per evitare il problema non funziona più.
Strategie di Deployment
Ora, con questi elementi in atto, possiamo esaminare alcune strategie di deployment che aiutano a ridurre il rischio quando distribuisci le modifiche.
One box (canary)
Un deployment one box distribuisce le modifiche su un singolo server all'interno del parco macchine più ampio. In questo modo l'impatto di eventuali modifiche problematiche si riduce a un solo host.
Fai il deploy e lasci che la modifica resti attiva per un po', ricevendo una piccola frazione del traffico complessivo. Configuri il monitoraggio e gli allarmi su questo server, così vieni avvisato se qualcosa si rompe.
Deployment Progressivi
Un deployment progressivo ti permette di distribuire in base a una percentuale nel tempo, in modo che, in caso di errore catastrofico, tu lo individui prima che colpisca tutte le macchine e si possa quindi procedere con il rollback.
Rollout Regionale
Con la crescita dell'azienda, ti ritroverai ad avere deployment multi-regione. Invece di distribuire in tutte le regioni contemporaneamente, puoi fare deploy prima in una regione specifica (in genere quella con il traffico più basso).
Casi in cui questo non si applica
App store
Pubblicare un'app mobile non è del tutto compatibile con queste indicazioni. La coda di revisione dell'app store rallenta il ritmo di deployment e richiede una strategia diversa.
Ambienti Certificati
Dispositivi medici, avionica, controllo industriale, ecc. Non puoi fare deploy continuo se un ente regolatore deve certificare la build.
On-prem / Self-hosted
Non puoi controllare l'aggiornamento. Puoi comunque fare deploy continuo su tutto ciò che gestisci, ma devi comunque versionare ogni modifica e sarà il cliente a decidere quando adottarla.
Da Dove Iniziare
Non fare tutto in una volta. L'ordine conta:
- Rendi la CI verde e veloce. Idealmente sotto i 15 minuti
- Ottieni metriche e allarmi su tasso di errore, latenza e disponibilità. È la parte più importante dell'intero processo
- Metti ogni modifica rischiosa dietro un flag
- Aggiungi one-box + rollback automatico
- Elimina il calendario dei rilasci
- Trova un nuovo impiego per tutto il tempo extra ora che non pianifichi più i rilasci
La maggior parte dei team con cui ho lavorato impiega circa un trimestre per completare questo percorso. La parte facile sono gli strumenti. La parte difficile è il processo organizzativo e abbattere l'illusione che i rilasci pianificati siano sicuri.
Se il tuo team usa un calendario di rilasci e vuole uscirne, è proprio il lavoro che faccio. Scrivimi in DM.
