Strategie di rilascio: blue-green e canary

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Blue-green dà il cambio istantaneo tra due vetri completi (Blue/Green) con il più semplice ritorno. Canary aumenta gradualmente la quota di traffico sulla nuova versione sotto il controllo dei gate SLO (latitanza, errato-rate, metriche aziendali). Per il iGaming è un modo per rilasciare senza downtime al culmine di tornei e promozioni, mantenendo un p99 stabile e qualità.

1) Quando scegliere

Blue-green - rilascio rapido, complessità minima, serve un budget cluster/risorse doppio. Ottimo per l'API/fronte senza la complessa migrazione state.
Canary - rilasci ad alto rischio (nuovi flow, cambiamenti critici), permette di «catturare» il degrado dell '1-5% del traffico. Richiede telemetria e gate automatiche.

2) Principi architettonici

1. Routing a livello L7: bilanciatore/Ingress/servizio-mesh (moduli di traffico ponderato, cookie/flag-routing).
2. Le dipendenze isolate sono configurazioni, phicheflagi, segreti, cache separate per le revisioni.
3. Compatibilità dei dati: migrazioni di database in avanti-compatibili (expand→migrate→contract).
4. Osservabilità: etichette/etichette di versione separate in metriche/loga/trailer.
5. Auto-gate: confronto p95/p99, error-rate, business KPI; rollback automatico.

3) Blue-green - pattern base

Flusso

1. Espandiamo Green (copia Blue) e riscaldiamo la cache/connessione.
2. Avviamo i test health/smoke.
3. Sposta il traffico (DNS/LB/Ingress) a Green.
4. Teniamo Blue calda come fallback fino alla fine della finestra.

Esempio: passaggio a livello Ingress (idea)

yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80

Pro/contro

Semplice ritorno (restituito Blue).
Tempo di lancio prevedibile.
Richiede la duplicazione delle risorse.
Il rischio di un Big Bang senza la misura del canarino.

4) Canary: aumento graduale

Flusso

1. Controllo del traffico shadow (opzionale) 1% del traffico reale, 5% 25% 50% 100%.
2. Su ogni gradino ci sono gate SLO/metriche aziendali.
3. In caso di degrado, recupero automatico e salvataggio degli artefatti diagnostici.

Esempio: Argo Rollouts (frammento)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100

Esempio: Flagger + Istio/NGINX (idea)

yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

5) Riscaldamento e gestione dello stato

Cache/sorgenti: sposta Redis/HTTP-cache/CDN, prepara le connessioni warm-pool al database/PSP.
ML/LLM/modelli - Scarica pesi/indici/embedding, cache KV, richieste di riscaldamento primarie.
File/manufatti: contenuti statici, modelli, confighi - invia in anticipo al volume/sidecar locale.
Phicheflagi: rollout per 1-5% del pubblico/segmento, capacità di emergency-kill.

6) Database: strategia «expand migrate»

1. Expand - Aggiungere nullable/nuove colonne/indici, supportare entrambe le versioni.
2. Migrate: il codice utilizza un nuovo schema; le vecchie strade rimangono validi.
3. Contract - Rimuoviamo i vecchi campi/indici dopo la scansione completa.

I registri registrano la versione dello schema e del client; tutti i cambiamenti sono idipotenti.
Per le migrazioni pesanti, i giubbotti di fondo, il throttling e lo stop-the-world sono finestre in sintonia.

7) Osservabilità e gate (SLO/SLA)

Metriche SRE: p50/p95/p99, error-rate, saturation (CPU/GPU/IO), queue-depth, ora di partenza fredda.
Metriche aziendali: conversione dei pagamenti, successo delle scommesse, tempo di output (TTW), risposte promozionali.
Qualità del contenuto/LLM: tokens/s, lunghezza della risposta, tossicità, AG-score.
Gate: Promozioni auto/rientro in caso di uscita dalle soglie e/o in caso di caduta della metrica utile.

gate:
p95_latency_ms <= 250 error_rate %  <= 1. 0 payment_conv  >= baseline - 0. 3%
action:
promote      rollback

8) Lancio-orchestrazione e integrazione con CI/CD

GitOps - Modifica di versioni/peso tramite PR in un repository manifesto.
Automezzi: smoke/e2e prima dell'inizio del traffico.
Piano di rilascio: pianificazione delle graduatorie canary, responsabili, canali di ChatOps, finestre di ripristino.
Archiviazione dei manufatti: confighi di routing, snap-shot di dashboard, logi di confronto delle metriche.

9) Multiregion e edge

Ordine: prima la regione meno critica/RR, poi la regione principale.
Latency-based routing: controlla le SLO locali; Non mischiare il traffico senza un motivo.
R-visione: Blue nella regione-A può diventare un sito per Green nella regione-B.

10) Sicurezza e compilazione di rilascio

Immagini/liste firmate, SBOM; Verifica delle firme nei policy admision.
Segreti: solo manager esterni; versioni indipendenti per Blue/Green.
PII/regionalità: non allontanare il traffico dal PII dalla regione «straniera»; mascherare i fogli durante il confronto.
Chi ha dato il via libera, quali gate hanno funzionato, dov'è la restituzione?

11) Esempi di configurazione

Linea canaresca per cookie/intestazione NGINX (idea)

nginx map $http_x_canary $canary {
default 0;
"1"   1;
}

upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }

server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}

Feature-flag «fractional rollout»

yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true

12) Runbooks (script tipici)

Altezza p99 sul canaro: interrompere la promozione, aumentare il batch/timeout, disattivare i fili pesanti attraverso le bandiere, riavviare una porzione.
Riduzione della conversione dei pagamenti: confronta le rotte PSP/Fici, abilita la logica shadow, ripristina su stabile.
Problema con la migrazione del database: congelamento del traffico di scrittura, attivazione della modalità read-only, ripristino dello schema (se possibile), correzione di emergenza.
L'incidente del PII è tagliare la versione canaresca, ricontrollare i segreti, rendicontare e controllare.

13) Assegno-foglio di implementazione

1. Definire il criterio: dove si trova il blue-green, dove si trova il canary; che è considerato «critico».
2. Impostare un instradamento ponderato (Ingress/mesh/router).
3. Fissare i gate SLO e i rimborsi automatici.
4. Implementare il expand→migrate→contract per il database; Test sulle migrazioni.
5. Attivare il riscaldamento della cache/modello e delle connessioni warm-pool.
6. Immettere il GitOps e il registro di tutte le azioni di lancio.
7. Visualizza il confronto delle metriche (la vs canaresca è stabile).
8. Fai clic su game-day per simulare il ritorno/fallimento del gate/problema del database.
9. Documentate runbooks e pulsante rosso (kill-switch).
10. Pianificare il rilascio multiplo a turno, non contemporaneamente.

14) Anti-pattern

Rilascio canario senza gate e telemetria in seguito alla rilevazione del degrado.
Combinazione diagramma database: migrazioni distruttive fino alla risoluzione del codice.
Una singola cache/coda condivisa per Blue e Green senza isolamento ha un impatto reciproco.
Failover DNS a bassa TTL senza controllo - «flapping» del traffico.
I segreti/confighi comuni a entrambe le revisioni sono un ritorno difficile.
Il traffico in silo senza shadow/smoke è un rischio di Big Bang.
Nessun kill-switch/feature-flag da spegnere rapidamente.

Riepilogo

Blue-green fornisce il cambio immediato e semplice, canary il rischio gestito e il rilevamento precoce dei problemi. Nel iGaming entrambi i pattern sono combinati, il canaro sui cambiamenti «acuti» + blue-green come meccanismo di base senza downtime. Aggiungete i gate SLO, il riscaldamento, la compatibilità del database e l'isolamento delle dipendenze - e le release saranno prevedibili, i rimborsi sono rapidi e le metriche p99 e business sono stabili anche durante i periodi di picco.