Release Blue-Green e Canary

(Sezione Architettura e Protocolli)

1) A cosa servono gli «scarichi sicuri»

Nei sistemi di rilascio moderni non è solo la consegna del codice, ma anche un esperimento gestito in vendita: minimizziamo al contempo il rischio (non interrompiamo gli utenti) e riduciamo i tempi di feedback (vediamo rapidamente l'effetto). Due strategie classiche, Blue-Green e Canary, lo risolvono in modo diverso, ma con un obiettivo comune: downtime zero, ritorno rapido, osservazione SLO.

2) Definizioni di base

Blue-Green

Due copie complete di un ambiente prod: attivo (Blue) gestisce il traffico, passivo (Green) prepara una nuova versione. Il cambio è atomico (switch/flip) a livello di bilanciatore/router. Se peggiora, torniamo subito alla Blue.

Canary

Le parti sono: prima un piccolo% del traffico (per esempio 1-5%), osserviamo le metriche/SLO, poi aumentiamo la percentuale (10% → 25% → 50% → 100%). In caso di degrado, ripristinare o interrompere il passo stabile precedente.

3) Quando l'approccio è migliore

• Ci serve una rimonta istantanea senza manovre complesse.
• Architettura/budget: doppia duplicazione dell'infrastruttura.
• Vogliamo migrare o aggiornare la piattaforma in modo isolato.
• L'applicazione/pool di connessioni è sensibile allo stato progressivo «misto».

• Devi ridurre al minimo i blast radius e vedere il comportamento sulla percentuale di utenti.
• Alta frequenza di rilascio, consegna progressiva come norma.
• Ci sono osservabilità matura e gate automatiche (error budget, latency, conversion).
• Il team di alimentari vuole verificare l'impatto sulla conversione, la ritenzione, LTV e così via.

4) Principi generali per il successo del lancio

Disegni Idempotent - stessa immagine/pacchetto in tutte le fasi.
Configurazione determinata: config come codice, paragonabilità degli ambienti.
Osservabilità by design: fogli, metriche, tracciabili, alert; SLI/SLO in anticipo.
Ripristino rapido e automatico: il pulsante/comando di ripristino è una parte del pipline, non una magia manuale.
Le modifiche compatibili agli schemi sono la strategia di espand-migrate-contract (vedere l'articolo 10).
Routing a livello L7 (preferibilmente): flessibilità di intestazione/cookie/percorsi/API.

5) Blue-Green: architettura e processo

5. 1 Topologia

Due protesi: Blue (attivo) e Green (candidato).
Dipendenze esterne comuni: CDN, API esterne, code Il database è un caso speciale (vedere l'articolo 10).
Punto di cambio: bilanciatore/Ingress/Gateway.

5. 2 Flow passo passo

1. Solleviamo Green sotto un nuovo manufatto (vNext), facciamo dei test di smog.
2. Prova auto contro Green (e2e, contrattazione, regressione).
3. Riscaldare la cache/sessioni (se applicabile), sincronizzare i giubbotti/code di sfondo.
4. Spostiamo il traffico a Green: flip atomica (DNS TTL basso, Route/Listener swap, Ingress weight = 100%).
5. Osserviamo SLO nei primi minuti/ore (golden signals: latency, errors, saturation + metriche aziendali).
6. I problemi includono il ritorno immediato a Blue (flip back).

5. 3 Pro/Contro

I vantaggi sono il ritorno istantaneo, il modello mentale semplice, l'isolamento puro.
Contro: raddoppio dell'infrastruttura, complessità con componenti stateful e migrazioni dei dati.

6) Canary: architettura e processo

6. 1 Topologia

Un unico cluster prod; più versioni del servizio (stabile e canary) in un unico fronte.
Il traffico si divide per bilancia (1-5-10-25-50-100%) o per target (titolo/cookie/ID).

6. 2 Flow passo passo

1. La release canary nello stesso cluster/ASG/NSG.
2. Instradamento di una parte del traffico (ad esempio 1-5%) su canary.
3. Controlli automatici SLI/SLO e metriche aziendali gate in CI/CD (errore rate, p95 latency, CPU/RES, conversione, rifiuto/restituzione).
4. Aumento passo per passo della quota di traffico durante il passaggio dei gate.
5. Rollout completo fino al 100% e disattivazione della versione precedente; in caso di degrado - auto-rollback.

6. 3 Pro/Contro

I vantaggi sono il rischio minimo per la maggior parte degli utenti, la soluzione data-driven.
Contro: ci vuole un'osservazione matura, un routing adeguato, un rischio di versione skew tra le istanze.

7) Routing del traffico

Livello L4: bilanciamento IP/porte semplice, ma poco flessibile.
Livello L7: regole HTTP/S - percorso, host, intestazione, cookie, User-Agente, GeoIP, SNI.

• Weighted routing (peso 1-100%).
• Header-based/cookie-based.
• Sessione stickover( importante per gli script di stateful/cache).
• Shadow/Traffic mirroring (specchiamo le query in una nuova versione segreta).

8) Strumenti e implementazioni (esempi)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS; GCP Load Balancing + NEG; Azure Front Door/App Gateway.
Piattaforme CD: Spinnaker, Argo CD, GitHub Action + Progressive Delivery plugin, GitLab/CD.

9) Osservabilità, SLI/SLO e gate

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Metriche aziendali: conversione, autorizzazioni, pagamenti/progressi, assegno medio, disattivazione dei passi del vortice.

• Soglia di errore (ad esempio error rate canary ≤ baseline + X%).
• La latenza p95 è uguale alla baseline di più di un Livello.
• Soglia aziendale (ad esempio, il calo della conversione
• Errore budget SLO non deve essere accelerato.

Durata del passo: tempo minimo sufficiente per l'importanza statistica (dipende dal traffico).

10) Migrazione del database e compatibilità degli schemi

Regola principale: le release sono sicure se le versioni indietro e indietro sono compatibili.

1. Expand: aggiungiamo nuove colonne/indici/tabelle senza rompere la versione precedente.

2. Deploy app (legge/scrive in un nuovo schema, ma sa lavorare anche con il vecchio).

3. Migrate data (background/batch, idimpotente, con checkpoint).

4. Contract - Rimuoviamo i vecchi campi/file dopo la stabilizzazione.

Anti-pattern: migrazioni che richiedono un blocco esclusivo al momento del passaggio di Blue-Green; impossibilità di uno schema di downgrade «doppio record» senza deduplicazione.

11) Rimborso (rollback) e piani di incidente

Blue-Green: flip immediato su Blue; monitor delle code di fondo Green.
Canary: ritorno del peso (ad esempio, con il 25% indietro del 5% o 0%); abort automatico per gli alert.
Dati: strategia di ripetizione/compensazione elaborata (idempotency keys, pattern inbox/outbox, deduplicazione dei messaggi).
Phicheflagi: kill switch veloce per disattivare funzionalità parzialmente rotte.

12) Lavoro con stack e sessioni

Sticky sessions per i canarini, o conservare le sessioni esterne (Redis/Memcached) in modo che le versioni siano scambiabili.
Scaldare la cache in anticipo (Green warm-up) e considerare l'invalidazione nella flip.
Worker di sfondo: non permettere «corse» tra le versioni - Separare le code o «leadership» in versione.

13) Sicurezza e conformità

Accesso a Green/Canary - Zero Trust: account di assistenza, ruoli essenziali minimi.
Segreti e chiavi tramite KMS/Secret Manager; Attivare la rotazione.
Traffico: solo TLS; le versioni di endpoint'ov sono state chiaramente contrassegnate; Controllo delle attività di instradamento e di lancio.

14) Costi e prestazioni

Blue-Green raddoppia l'infrastruttura (in fase di rilascio o permanente) - fissa il budget.
Canary è più economico, ma richiede strumenti di osservazione e tempo di ingegneria per l'automazione.
Ottimizzazione: skailing automatico, ambiente ephemerale, riduzione della finestra di versioni parallele.

15) Assegno fogli

Prima del lancio

• Immagine/cartello riprodotto da una sola origine, le firme sono state convalidate.
• Test-piano, alert e SLO-gate sono configurati.
• Migrazioni database - In modalità expand, i piani di downgrade sono disponibili.
• Piano di ripristino - Verificato in staging/production-like.

Durante il lancio

• Le metriche e i fogli vengono confrontati con baseline.
• Per Canary - i passi e le soglie sono fissati; per Blue-Green - flip-back pronto.
• I comandi on-call sanno che c'è una finestra di feedback.

Dopo il lancio

• Lo SLO non è stato difettoso.
• Migrazione/pulizia post-lancio completata.
• Retrospettiva e aggiornamento playbook.

16) Errori frequenti e anti-pattern

Estrazione senza metriche: nessun dato, nessuna soluzione gestibile.
Miscelazione di schemi di database incompatibili, mancanza di strategia di downgrade.
Miscelazione casuale del traffico: niente stick, utenti che saltano tra le versioni.
Le dipendenze stateful nascoste (dischi locali, in-memory cache).
Il lungo DNS-TTL interferisce con la rapida flip (Blue-Green).
La mancanza di auto-gate, con soluzioni manuali che rallentano e aumentano i rischi.

17) Approcci combinati

Blue-Green + Canary: prima sforna Green, poi dentro Green distribuisce Canary per i singoli servizi.
Shadow/Migration - Prima di Canary, spostiamo il traffico mirroring verso la nuova versione.
Feature flags (progressive delivery) - La funzione viene attivata sopra la versione stabile dei flag scuri per segmenti.

18) Esempi di script (sketch)

1. Espandiamo Green (v2) dietro al nuovo Listener/Ingress.

2. Riscaldamento della cache, controllo readonly, smoke.

3. Cambiare peso a Green = 100%.

4. Osservare SLO 30-60 minuti; Se tutto va bene, spegniamo la Blue.

1. Deposito canary (repliche 5%).

2. Attiviamo il traffico del 5% per account/test interni.

3. Gate automatico: errore rate baseline + 0. 3%, p95 ≤ +20ms.

4. Alziamo il 10 del 25% ogni N minuti.

5. Tradurremo al 100% la fittiflag in tutti i segmenti; Cancelliamo la vecchia versione.

19) Variazioni per architetture diverse

Monolith: Blue-Green è più semplice, Canary è più difficile a causa dell'indissolubilità del Fich; Usate i phicheflagi.
Microservizi: Canary è naturale; Tenere traccia dei contratti tra server (consumer-driven contracts).
Servizi di Stateful: preferisci Blue-Green con migrazioni elaborate e stick.

20) Confronto breve (curriculum)

Velocità di ripristino: Blue-Green = istantaneo; Canary = veloce, ma con un peso di recupero.
Costo dell'infrastruttura: Blue-Green Canary ↔︎/↓.
Rischio per gli utenti: Canary è inferiore (controlliamo la quota).
Complessità di implementazione: Blue-Green più facile da avviare Canary richiede una forte osservabilità e automazione.
Compatibilità dati/diagrammi: critico per entrambi; pianificare l'expand-migrate-contract.

21) Totale

Blue-Green e Canary non sono strategie che si escludono reciprocamente, ma elementi di consegna progressiva. La scelta dipende dai limiti di costo, dalla maturità di osservabilità e dalla natura dei cambiamenti. Indipendentemente dall'approccio, il rilascio sostenibile si basa su quattro pilastri: automazione, osservabilità, interoperabilità inversa e ritorno rapido.