Il downtime durante i deployment non è più accettabile per nessun sistema di produzione serio. Gli utenti si aspettano disponibilità continua, e anche brevi interruzioni erodono fiducia e ricavi. Le tre strategie dominanti per ottenere deployment senza downtime sono blue-green, canary e rolling updates. Ciascuna comporta compromessi distinti in termini di costi infrastrutturali, velocità di deployment e sicurezza del rollback. Scegliere l'approccio giusto dipende dall'architettura della tua applicazione, dai modelli di traffico e dalla maturità del team. Abbiamo implementato tutte e tre in diversi progetti dei clienti e possiamo offrire indicazioni concrete su quando ciascuna strategia eccelle.
I deployment blue-green mantengono due ambienti di produzione identici. Il traffico viene instradato interamente verso l'ambiente attivo mentre quello in standby riceve la nuova release. Una volta validato, uno switch del load balancer sposta tutto il traffico verso l'ambiente aggiornato istantaneamente. Il vantaggio principale è un rollback pulito: se emergono problemi, si reindirizza il traffico all'ambiente precedente in pochi secondi. Il costo è mantenere il doppio dell'infrastruttura durante la finestra di deployment. Per clienti con requisiti di conformità rigorosi o migrazioni di database complesse, il blue-green fornisce il percorso più sicuro perché è possibile validare l'intero stack in isolamento prima che qualsiasi utente veda il cambiamento.
I deployment canary adottano un approccio più graduale. Una piccola percentuale di traffico, tipicamente dal cinque al dieci percento, viene instradata verso la nuova versione mentre il resto rimane sulla release corrente. Controlli di salute automatizzati e confronti delle metriche aziendali vengono eseguiti continuamente durante la fase canary. Se i tassi di errore aumentano o le metriche chiave si degradano, il canary viene automaticamente annullato. Se le metriche rimangono stabili, il traffico viene progressivamente spostato fino a quando la nuova versione gestisce il cento percento. Questa strategia è ideale per applicazioni ad alto traffico dove anche una release validata potrebbe rivelare edge case che appaiono solo su larga scala.
I rolling updates sostituiscono le istanze in modo incrementale all'interno dello stesso ambiente. Kubernetes rende questa la strategia predefinita, drenando le connessioni dai pod vecchi mentre ne avvia di nuovi. Il processo è efficiente in termini di risorse poiché non si eseguono mai più di un piccolo surplus di istanze. Tuttavia, i rolling updates significano che durante la finestra di deployment, due versioni dell'applicazione servono traffico simultaneamente. Questo richiede attenzione ai contratti API retrocompatibili e alle modifiche dello schema del database. Imponiamo un gate di test dei contratti nel CI che verifica che la nuova versione possa coesistere con quella precedente prima che qualsiasi rolling update proceda.