Rilasciare il software significava una finestra di manutenzione e dita incrociate. I team moderni utilizzano strategie che rendono i rilasci una routine e la scelta implementazione blu-verde vs canarino è una delle prime che dovrai affrontare. Entrambi riducono il rischio, ma lo fanno in modi opposti: uno prepara una sostituzione completa, mentre l’altro testa un po’ alla volta con utenti reali.

Questa guida spiega come funziona ognuno di essi e quanto costa nella pratica. Abbiamo eseguito i piccoli esempi di routing degli utenti e rollback in Python 3.13 e l’output proviene da quell’esecuzione. Gli esempi Kubernetes sono illustrativi e non li abbiamo eseguiti. Trattare le percentuali e le soglie come esempi di partenza da adattare.

La risposta breve

Con la distribuzione blu-verde, esegui due ambienti di produzione identici. Uno serve gli utenti mentre distribuisci e testi la nuova versione, dall’altro, quindi trasferisci tutto il traffico in una sola mossa.

Con la distribuzione canary, la nuova versione viene eseguita accanto a quella vecchia. Gli invii una piccola percentuale di traffico reale, confronti i risultati e aumenti la condivisione passo dopo passo finché non serve tutti. Il nome deriva dai canarini minatori un tempo usati come avvertimento precoce di pericolo.

Blu-verde vs canarino fianco a fianco

Come funziona la distribuzione blu-verde

1. Blu è attivo e serve tutto il traffico.
2. Distribuisci la nuova versione a green, che non riceve traffico di utenti.
3. Testare a fondo il verde, nell’ambiente di produzione reale, utilizzando test del fumo e utenti interni.
4. Cambia il router, il bilanciatore del carico o il DNS per inviare il traffico al verde.
5. Osserva attentamente, con l’azzurro ancora in corsa e pronto.
6. Se qualcosa non va, torna indietro. Se tutto va bene, il blu diventa il prossimo ambiente inattivo.

In Kubernetes, puoi effettuare il passaggio modificando il selettore di un servizio, in modo che il traffico venga spostato su pod etichettati in modo diverso:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Punti di forza: È concettualmente semplice, puoi testare l’esatta configurazione di produzione prima che gli utenti la vedano e il rollback è quasi istantaneo. Punti deboli: L’infrastruttura duplicata può essere costosa, un bug che supera i test raggiunge tutti contemporaneamente e le sessioni aperte e il lavoro in volo necessitano di cure durante il passaggio. Se utilizzi DNS per lo switch, i record memorizzati nella cache possono ritardarlo. Nuovo ai concetti? Guarda il nostro tutorial Kubernetes per principianti.

Come funziona la distribuzione Canary

1. Distribuisci la nuova versione insieme a quella stabile.
2. Indirizza una piccola parte del traffico, ad esempio il 5%, verso il canarino.
3. Confronta tassi di errore, latenza e parametri aziendali con la versione stabile.
4. Se sano, aumenta al 25%, poi al 50%, quindi al 100%.
5. Se qualcosa peggiora, rimanda tutto il traffico alla versione stabile.

Molte squadre avviano un canary con personale interno, poi una regione a basso rischio e solo successivamente il pubblico più ampio.

Punti di forza: Una versione errata colpisce solo un piccolo gruppo e impari dal traffico reale che nessun ambiente di test può riprodurre completamente. Punti deboli: Sono necessari routing basato su percentuale e metriche per versione, le implementazioni richiedono più tempo e due versioni vengono eseguite insieme per un po’. Un piccolo canarino può anche essere troppo silenzioso per dare un segnale significativo, soprattutto nelle ore di scarso traffico.

Routing utente stabile

Scegliere una versione a caso per ogni richiesta offre agli utenti un’esperienza confusa, poiché potrebbero rimbalzare tra il vecchio e il nuovo. Una soluzione comune è quella di eseguire l’hashing di un ID utente stabile in un bucket, in modo che ogni utente riceva sempre la stessa risposta:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

La quota effettiva ha seguito da vicino l’obiettivo. Questo metodo ha altre due proprietà utili e la nostra analisi le ha confermate entrambe. Lo stesso utente ha ricevuto sempre la stessa versione. E tutti nel gruppo del 5% erano ancora inclusi al 25%, quindi nessuno che avesse già la nuova versione è stato spostato indietro man mano che il lancio cresceva.

Nei sistemi reali, un service mesh, un bilanciatore del carico o uno strumento come Argo Rollouts o Flagger solitamente gestisce questo routing, quindi non è necessario scriverlo tu stesso. È comunque utile capire cosa stanno facendo.

Automatizzare la decisione

Un canarino funziona solo se qualcuno confronta effettivamente le versioni. I controlli automatizzati sono più affidabili di una persona che guarda i grafici. Ecco l’idea centrale, confrontando il tasso di errore del canary con quello della versione stabile:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

Si noti il primo caso. Il suo tasso di errore sembra elevato, ma con solo 100 richieste non è ancora una prova sufficiente. Gli strumenti reali applicano statistiche più attente e esaminano insieme diversi segnali:

Il problema della banca dati

Il codice dell’applicazione può essere scambiato in pochi secondi, ma i dati no. Entrambe le strategie di solito condividono un database, quindi durante un’implementazione e dopo un rollback, la vecchia e la nuova versione devono funzionare entrambe con lo stesso schema.

La risposta standard è il modello espandi e contrai. Supponiamo di voler rinominare name in full_name:

1. Espandi: aggiungi la nuova colonna. Il vecchio codice non è interessato.
2. Migrazione: rilascia codice che scrive su entrambe le colonne e riempie le vecchie righe.
3. Switch: codice di rilascio che legge dalla nuova colonna.
4. Contratto: una volta che la vecchia colonna non viene più utilizzata, rimuoverla in una versione successiva.

Questa operazione richiede diversi rilasci, ma è possibile eseguire il rollback di ogni passaggio in modo sicuro. L’esecuzione di RENAME COLUMN in una volta sola interromperebbe qualunque versione prevedesse l’altro nome. Prestare attenzione anche alle modifiche dello schema a esecuzione prolungata, poiché possono contenere blocchi. Per ulteriori informazioni sull’argomento, leggi le informazioni sulle transazioni SQL.

Rolling e altre strategie

Una distribuzione Kubernetes esegue un aggiornamento in sequenza per impostazione predefinita, che si adatta a molti servizi. Anche un aggiornamento in sequenza cambia gradualmente, ma la sua quota è legata al numero di istanze e non analizza di per sé i risultati né si sofferma su metriche errate.

E i flag di funzionalità?

La distribuzione inserisce il codice sui server e il rilascio rende disponibile una funzionalità agli utenti. I flag di funzionalità li mantengono separati, consentendoti di attivare una funzionalità per gli utenti selezionati senza distribuire nulla. Funzionano molto bene con entrambe le strategie: schierarsi con la bandiera spenta, quindi attivarla gradualmente. Non sostituiscono queste strategie, poiché un flag non può proteggerti da una versione che si blocca all’avvio. Ricordarsi di rimuovere le vecchie bandiere, poiché si accumulano come debito tecnico.

Come scegliere

Possono anche essere combinati. Alcune squadre implementano un ambiente verde e poi spostano gradualmente il traffico verso di esso, ottenendo un ambiente pulito e un raggio di esplosione limitato. Qualunque cosa tu scelga, automatizzala tramite la tua pipeline CI/CD, come spiega la nostra guida alle azioni GitHub.

Errori comuni

• Apportare modifiche importanti allo schema. Il rollback non aiuta se il vecchio codice non è in grado di leggere i dati.
• Non esistono criteri di rollback. Decidi cosa significa “cattivo” prima dell’inizio del rilascio, non durante un incidente.
• Lasciare che gli ambienti vadano alla deriva. Se il verde differisce dal blu, i tuoi test dimostrano meno. Definiscili entrambi con infrastruttura come codice.
• Misurazione solo di parametri tecnici. Una versione può essere priva di errori e comunque interrompere il pagamento.
• Non praticare mai il rollback. Provalo, in modo che funzioni quando sei sotto pressione.
• Dimenticare i lavori in background. Anche i lavoratori e le attività pianificate necessitano di un piano durante un passaggio.

Considerazioni finali

Il blu-verde ti offre un passaggio pulito e veloce. Canary ti offre un’esposizione piccola e misurata. Se il tuo monitoraggio è ancora di base, inizia con aggiornamenti continui o blu-verde e investi in metriche per versione prima di provare i canary. Quindi prova un rollback sul tuo prossimo rilascio, incluso il database. Quel singolo esercizio tende a rivelare ciò che ha veramente bisogno di essere risolto.

Domande frequenti

Continua a imparare