Blue-Green Deployment: Come Fare Deploy Senza Paura
Come funziona il blue-green deployment, quando usarlo, come gestire le migrazioni del database e come combinarlo con canary release e feature flag.
In questo articolo:
- Come funziona il blue-green deployment
- Configurare una pipeline blue-green
- Migrazioni database con blue-green
- Blue-green vs. canary: quando usare quale
- Conclusione
Il blue green deployment è una strategia di rilascio che mantiene due ambienti di produzione identici e commuta il traffico tra loro. Un ambiente è sempre attivo (riceve il traffico degli utenti); l’altro è inattivo (disponibile per il prossimo deployment). Quando sei pronto per rilasciare, distribuisci nell’ambiente inattivo, lo verifichi e poi commuti il load balancer per instradare tutto il traffico all’ambiente appena distribuito.
Il risultato: deployment con downtime quasi zero, capacità di rollback istantaneo e un ambiente stabile per la verifica pre-produzione. I team che implementano il blue-green deployment in modo consistente riportano un aumento della frequenza di deployment da mensile a settimanale o giornaliero, e i tempi di rollback scendono da 30-60 minuti a meno di 2 minuti.
Come funziona il blue-green deployment
I due ambienti, chiamati blue e green, sono identici in configurazione, infrastruttura e connettività ai servizi condivisi (database, code di messaggi, API esterne). In qualsiasi momento, uno serve tutto il traffico di produzione; l’altro è inattivo.
Il processo di deployment:
Passo 1: Distribuisci nell’ambiente inattivo. La nuova versione dell’applicazione viene distribuita in qualunque ambiente sia attualmente inattivo. Nessun utente è influenzato perché l’ambiente inattivo non riceve traffico.
Passo 2: Verifica la nuova versione. Esegui test automatizzati, smoke test e controlli di salute contro l’ambiente inattivo. Poiché l’ambiente è connesso allo stesso database della produzione, i test sono effettuati su dati realistici.
Passo 3: Commuta il traffico. Aggiorna il load balancer per instradare il 100% del traffico all’ambiente appena distribuito. Il cambio richiede millisecondi. Gli utenti non vivono alcun downtime.
Passo 4: Monitora. Osserva i tassi di errore, la latenza e le metriche di business per 10-30 minuti dopo il cambio. Se le metriche degradano, riporta il load balancer all’ambiente precedente. Il rollback è immediato e non richiede un nuovo deployment.
Passo 5: Decommissiona il vecchio ambiente (o lascialo inattivo). Una volta che il nuovo deployment è stabile, il vecchio ambiente diventa il nuovo ambiente inattivo, pronto per il prossimo deployment.
Configurare una pipeline blue-green
Una pipeline blue-green minimale richiede:
Due ambienti identici. Se sei su infrastruttura cloud (AWS, GCP, Azure), usa infrastructure-as-code (Terraform, Pulumi) per garantire che entrambi gli ambienti siano sempre sincronizzati. La deriva della configurazione tra gli ambienti è una causa comune di fallimento.
Un load balancer con controllo del routing. AWS Application Load Balancer, GCP Cloud Load Balancing, Nginx o HAProxy supportano tutti il routing pesato che ti permette di commutare il traffico tra target group. Il cambio dovrebbe essere automatizzabile dalla tua pipeline CI/CD.
Una pipeline di deployment con passi di gate. La pipeline distribuisce nell’ambiente inattivo, esegue la verifica e procede solo al cambio del traffico se tutti i gate passano. Se qualsiasi gate fallisce, la pipeline si ferma. L’ambiente attivo non è influenzato.
Suite di smoke test. Un piccolo insieme di test end-to-end che verificano i flussi utente principali: un utente può accedere, può completare una transazione, l’API risponde correttamente alle richieste chiave.
Migrazioni database con blue-green
Il vincolo del blue-green deployment è lo stato del database condiviso. Entrambi gli ambienti puntano allo stesso database. Una modifica dello schema compatibile con la nuova versione dell’applicazione ma che rompe la vecchia significa che non puoi fare rollback senza fare anche il rollback dello schema.
La soluzione è il pattern expand-contract per le modifiche al database.
Non distribuire mai una modifica dello schema che rompe il codice insieme a una modifica del codice. Le modifiche distruttive vanno in un deployment separato che precede il deployment del codice. La sequenza:
- Distribuisci la migrazione del database (retrocompatibile: aggiungi colonna, aggiungi tabella). Sia il vecchio che il nuovo codice funzionano con questo schema.
- Distribuisci il nuovo codice applicativo che usa il nuovo stato dello schema.
- Distribuisci la migrazione del database per rimuovere il vecchio stato dello schema (elimina colonna, elimina vecchio indice). Il vecchio codice non è più in esecuzione.
Questa sequenza in tre passi significa che ogni singolo deployment è sicuro da fare rollback, perché lo schema ad ogni passo è compatibile con il codice nei passi adiacenti.
Blue-green vs. canary: quando usare quale
Il blue-green deployment commuta il 100% del traffico istantaneamente. Il canary deployment commuta prima una piccola percentuale. La scelta dipende dal profilo di rischio del cambiamento.
Usa il blue-green quando:
- Il cambiamento è ben testato e il team è fiducioso nella nuova versione.
- Il cambiamento riguarda tutti gli utenti in modo uniforme, quindi non c’è beneficio nel testarlo prima su un sottoinsieme.
- Il team vuole il processo di deployment più semplice possibile con rollback rapido.
Usa il canary deployment quando:
- Il cambiamento ha modifiche al comportamento rivolte agli utenti che potrebbero interagire con segmenti utente o pattern di dati specifici.
- Il team vuole validare sotto carico di produzione reale prima del rollout completo.
- Il cambiamento riguarda un componente ad alto traffico e alto rischio.
Le due strategie sono complementari. Molti team usano il blue-green come predefinito e aggiungono il routing canary per le release ad alto rischio. I feature flag forniscono un terzo livello per i cambiamenti di comportamento che necessitano di un controllo ancora più granulare.
Conclusione
Il blue-green deployment rimuove la paura dal rilascio. Quando il rollback richiede 90 secondi e l’ambiente di verifica è identico alla produzione, il deployment diventa un’operazione di routine piuttosto che un evento ad alto stress.
I team che implementano il blue-green deployment in modo consistente raggiungono frequenze di deployment di 5-10 a settimana da cadenze mensili, con tassi di fallimento dei cambiamenti inferiori al 3%. L’investimento nell’infrastruttura è di 1-2 settimane di tempo ingegneristico. Il ritorno è misurabile nel primo mese.
Hai un codebase con questi problemi? Parliamo del tuo sistema