Blue-Green Deployment
Due ambienti di produzione completi, con il traffico commutato da uno all'altro — consentendo un'inversione completa e immediata se il nuovo ambiente non si comporta correttamente.
Distribuzione e abilitazione · Fase 05 · Come lavoriamo
Il rilascio è una decisione, non un evento.
Lo sviluppo e l'integrazione producono software verificato — ma il software verificato non è ancora software in produzione. Questa fase stabilisce come, quando e con quale sicurezza quel software venga esposto al traffico di produzione reale e assicura che le persone responsabili della sua gestione siano pronte prima che arrivi.
Il deployment in OpenQCore è considerato un'esposizione controllata al rischio, non un singolo momento irreversibile. Un rilascio non è "completato" quando il codice raggiunge la produzione. È completato quando è stato esposto gradualmente, osservato in condizioni reali e confermato sicuro — con una via definita per tornare indietro se non lo fosse.
Non questa domanda
"Il codice è pronto per essere rilasciato?"
Questa domanda, invece
"Come esponiamo questa modifica agli utenti reali in modo da limitare il raggio d'impatto di ciò che non abbiamo previsto — e possiamo ripristinarla rapidamente se necessario?"
Rilascio progressivo · Contenimento del rischio · Reversibilità · Prontezza · Abilitazione
Perché il deployment segue la verifica
Verificato non equivale a dimostrato in produzione.
La fase precedente conferma che una modifica soddisfa i suoi criteri di accettazione nei test. Non conferma come quella modifica si comporti sotto il carico reale di produzione, con il comportamento reale degli utenti, o con le interazioni reali con sistemi che non possono essere completamente replicati in un ambiente di test. La fase di Deployment & Enablement esiste proprio perché questo divario è reale — e perché colmarlo in sicurezza richiede una disciplina a sé stante.
Pronto per il deployment → Esposizione controllata in produzione
Perché la disciplina nel deployment è importante
La velocità senza reversibilità non è progresso.
La stessa ricerca DORA presentata durante Development & Integration — "Accelerate" (2018) di Forsgren, Humble e Kim — associa le metriche di throughput a due metriche di stabilità che sono particolarmente rilevanti in questa fase.
Frequenza di deployment
Quanto spesso un'organizzazione rilascia con successo in produzione.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps research.
Tempo per ripristinare il servizio
Quanto tempo richiede per ripristinare il servizio quando un deployment degrada la produzione.
Forsgren, Humble & Kim, Accelerate (2018); DORA, State of DevOps research.
Le organizzazioni ad alte prestazioni, secondo questa ricerca, non si limitano a rilasciare spesso: lo fanno in modo tale da mantenere brevi i tempi di recupero quando qualcosa va storto. OpenQCore considera questi aspetti un unico obiettivo, non un compromesso: le pratiche in questa fase sono pensate per rendere il deployment sia frequente sia rapidamente reversibile.
Strategie di rilascio progressivo
Separare la decisione di rilasciare dalla decisione di distribuire.
Le pratiche formalizzate nell'influente "Continuous Delivery" (2010) di Humble e Farley distinguono il deploy di una modifica dal suo rilascio agli utenti — una distinzione che OpenQCore considera una scelta progettuale fondamentale su come il software raggiunge la produzione.
Canary Releases
Una nuova versione viene esposta prima a una piccola frazione del traffico reale, osservata rispetto a segnali definiti, e viene estesa solo se quei segnali si mantengono.
Feature Flags
Il codice può essere distribuito in produzione rimanendo inattivo per gli utenti — separando l'atto di consegnare il codice dall'atto di esporre una funzionalità.
Ambienti di deployment e promozione
Una modifica si guadagna il diritto di andare in produzione. Non viene inviata direttamente.
Una modifica passa attraverso ambienti definiti — sviluppo, pre-produzione e produzione — con verifiche esplicite a ogni promozione, non un singolo superamento di test seguito da un rilascio diretto.
Sviluppo
Dove una modifica viene costruita e verificata inizialmente in isolamento.
Pre-produzione
Dove una modifica viene verificata rispetto a condizioni, configurazioni e integrazioni simili a quelle di produzione.
Produzione
Dove una modifica viene esposta al traffico reale — in modo progressivo e sotto osservazione.
Progettazione del rollback e del recupero
Il piano di rollback viene redatto prima del rilascio, non durante l'incidente.
Una strategia di rollback decisa mentre il sistema è già degradato è una strategia presa sotto pressione, con informazioni incomplete e spesso troppo tardi. OpenQCore definisce il percorso di rollback per una modifica prima che venga rilasciata — non dopo che qualcosa è andato storto.
Condizioni definite per l'attivazione del rollback
I segnali specifici che attiverebbero un rollback, concordati in anticipo invece di essere valutati sul momento.
Compatibilità dei dati e dello stato
Considerazione esplicita sulla sicurezza di un rollback alla luce di eventuali modifiche ai dati o allo schema introdotte dal rilascio.
Obiettivo di tempo di ripristino
Un obiettivo dichiarato su quanto rapidamente il servizio dovrebbe essere ripristinato se è necessario un rollback.
Infrastruttura come codice e riproducibilità
Un rilascio che non può essere ripetuto esattamente non può essere considerato affidabile.
I passaggi di rilascio sono definiti come codice — versionati, revisionati ed eseguiti in modo identico ogni volta — invece di essere eseguiti come azioni manuali dipendenti dalla memoria di un individuo sulla sequenza corretta. Questa è una pratica fondamentale nello stesso ambito di ricerca sulla continuous delivery citato sopra: un processo di rilascio che non può essere riprodotto esattamente non può essere verificato e non può essere automatizzato in modo sicuro.
Valutazione del rischio del rilascio
Ogni rilascio viene valutato prima che avvenga, non dopo.
In coerenza con il threat modeling introdotto durante Sviluppo e Integrazione, ogni rilascio viene valutato per il suo profilo di rischio specifico prima di procedere.
Raggio d'impatto
Quanti utenti, sistemi o flussi di lavoro sarebbero interessati se questa specifica modifica si comportasse in modo imprevisto.
Reversibilità
Quanto rapidamente e in modo pulito questa specifica modifica può essere annullata, se necessario.
Esposizione delle dipendenze
Quali sistemi a valle o team sono interessati da questo rilascio e se sono stati informati.
La pipeline di rollout progressivo
L'esposizione aumenta solo quando le evidenze lo supportano.
Canary (piccola percentuale) → Monitorare i segnali definiti → Ampliare l'esposizione → Monitorare i segnali definiti → Rilascio completo. In qualsiasi punto di questa sequenza, un rollback è un esito progettato — non un'improvvisazione d'emergenza. L'espansione allo stadio successivo è una decisione presa sulla base delle evidenze raccolte nella fase corrente, non un'impostazione predefinita che avviene automaticamente col tempo.
Questo approccio riflette il concetto di error budget, descritto in Site Reliability Engineering di Google (2016): una quantità definita e accettabile di instabilità che un sistema è autorizzato a spendere, usata per trasformare il compromesso tra velocità di rilascio e affidabilità in una decisione esplicita e misurata anziché implicita.
Abilitazione: Documentazione e Prontezza del Team
Un sistema che nessuno sa gestire non è davvero stato distribuito.
Il deployment è spesso considerato completo non appena il software è in produzione. OpenQCore lo considera invece completo solo quando le persone responsabili dell'operazione, del supporto e della risoluzione dei problemi di quel software sono effettivamente preparate a farlo.
Runbook operativi
Procedure documentate per attività operative comuni, modalità di guasto note e come rispondere ad esse.
Prontezza on-call
Conferma che le persone responsabili della risposta agli incidenti abbiano gli accessi, il contesto e le vie di escalation di cui hanno bisogno.
Trasferimento di conoscenza
Passaggio esplicito della conoscenza operativa al team o all'organizzazione che si occuperà del sistema d'ora in poi.
Il gate decisionale per il deployment
Un deployment procede perché le evidenze lo supportano — non perché è programmato.
Ogni deployment pianificato raggiunge un gate decisionale definito prima di procedere.
Esegui il deployment
La valutazione del rischio, il piano di rollback e la prontezza sono tutti soddisfatti — il rilascio procede.
Rimanda
Un rischio identificato non è ancora stato sufficientemente mitigato — il rilascio attende finché non lo sarà.
Ripristina
Una modifica distribuita ha attivato una condizione definita di rollback — lo stato precedente viene ripristinato.
Escalazione dell'incidente
Un rilascio ha causato un impatto che richiede una risposta formale all'incidente oltre a un normale rollback.
Un gate di deployment che non ritarda mai né esegue rollback non sta valutando il rischio — sta semplicemente registrando un programma.
Cosa produce questa fase
Un sistema attivo e la capacità di gestirlo.
A seconda dell'ambito dell'intervento, questa fase produce:
Runbook di deployment
La procedura specifica e ripetibile usata per distribuire questa modifica e modifiche future simili.
Piano di rollback
Le condizioni di trigger definite, la procedura e l'obiettivo di tempo di recupero per invertire questo rilascio.
Registro di promozione dell'ambiente
Documentazione su come la modifica è passata attraverso sviluppo, staging e produzione e cosa è stato verificato in ogni fase.
Documento di valutazione del rischio
Il raggio d'impatto, la reversibilità e l'esposizione delle dipendenze valutati prima del rilascio.
Materiali per l'abilitazione del team
Runbook, conferma della prontezza del personale on-call e trasferimento delle conoscenze completati prima del passaggio di consegne.
Rapporto sul rilascio progressivo
I segnali osservati in ogni fase di esposizione e le evidenze a supporto dell'espansione fino al rilascio completo.
Dal rilascio al monitoraggio e all'ottimizzazione
Essere in produzione non significa essere compresi.
Deployment & Enablement produce un sistema che funziona in modo sicuro in produzione, con le persone responsabili preparate a gestirlo. Tuttavia non genera ancora una comprensione continua di come quel sistema si comporta nel tempo, né un meccanismo strutturato per migliorarlo. Questo è lo scopo della fase successiva e finale di questa metodologia.
Esposizione controllata in produzione → Prontezza operativa → Monitoraggio e Ottimizzazione
Fase 06
Monitoraggio e Ottimizzazione
Comprendere come un sistema attivo si comporta realmente e migliorarne continuamente il funzionamento sulla base di evidenze reali.
Riferimenti di ricerca e metodologici
Forsgren, N., Humble, J., & Kim, G. — Accelerate: The Science of Lean Software and DevOps (2018); Google Cloud, ricerca DORA sullo stato del DevOps
Fonte delle metriche di frequenza di deployment e dei tempi di ripristino citate sopra.
Humble, J. & Farley, D. — Continuous Delivery: Rilasci software affidabili tramite automazione di build, test e deployment (2010)
Fonte della distinzione deploy/release, del blue-green deployment e dei principi di infrastructure-as-code citati sopra.
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (a cura di) — Site Reliability Engineering: How Google Runs Production Systems (2016)
Fonte del concetto di error budget citato nella sezione sul rilascio progressivo sopra.