Strategie di distribuzione

Le procedure DevOps prevedono cicli di rilascio frequenti che assicurano vantaggi alle organizzazioni e ai relativi utenti finali in molti modi diversi. Poiché le singole distribuzioni sono più ridotte, sono anche più rapide e meno stressanti, ma possono comunque verificarsi dei problemi. Per ridurre la possibilità di problemi, è necessario adottare una strategia di distribuzione più adatta alle esigenze dell'organizzazione.

Si conosce già l'approccio in stile "distribuzione epica", a cui qualcuno si riferisce anche come strategia del "Big Bang". Si è già visto come questo metodo non funzioni bene per le applicazioni moderne. Esistono diverse altre strategie di distribuzione che si sono diffuse nel contesto dei moderni ambienti operativi e ognuna presenta punti di forza e punti deboli a seconda della situazione.

Strategia di distribuzione in sequenza

La strategia di distribuzione in sequenza adotta un approccio graduale all'introduzione di nuove versioni del codice. La nuova versione viene gradualmente implementata in un certo periodo di tempo, aumentando gradualmente le istanze del nuovo codice riducendo le istanze del vecchio. Di conseguenza, le istanze precedenti e nuove coesistono nella destinazione di distribuzione durante l'implementazione. Ad esempio, è possibile aggiornare il software in un server, una macchina virtuale o un contenitore alla volta.

Un vantaggio di questa strategia è che è possibile monitorare il nuovo codice nell'ambiente di produzione per assicurarsi che soddisfi gli standard in termini di prestazioni, sicurezza, affidabilità e di altro genere prima che sia ampiamente distribuito.

Strategia di distribuzione blu/verde

La strategia di distribuzione blu-verde usa due ambienti separati che vengono mantenuti il più simili possibile e sono entrambi in grado di gestire il traffico di produzione. Un ambiente gestisce il carico di produzione corrente mentre l'altro ospita la nuova versione del software in modo da poterlo convalidare prima di spostare il traffico. Quando sei soddisfatto che la nuova versione è integra, puoi trasferire tutto il traffico immediatamente o aumentare gradualmente la quota di traffico che passa al nuovo ambiente mentre monitori i risultati.

L'ambiente blu è quello che attualmente gestisce il traffico di produzione. L'ambiente verde è la controparte parallela. Prima distribuisci e convalida la nuova versione del software nel verde, quindi instrada il traffico di produzione dal blu al verde. Dopo il cutover, i ruoli possono passare: il verde diventa l'ambiente attivo e il blu può essere preparato per la versione successiva.

Un vantaggio di questa strategia è che è possibile passare rapidamente, spesso con poco o nessun tempo di inattività. È anche relativamente facile indirizzare il traffico all'ambiente precedente se si verifica un problema dopo la pubblicazione del nuovo ambiente.

Strategia di distribuzione Canary

La strategia di distribuzione canary combina alcuni elementi della distribuzione in sequenza con quelli della distribuzione blu/verde. Il passaggio non avviene in una sola operazione, ma si distribuisce la nuova versione in una parte limitata dell'ambiente di produzione e quindi si sposta gradualmente l'intero traffico alla nuova versione. Il software viene distribuito in passaggi incrementali a un numero limitato di istanze o utenti finché non si verifica che funzioni correttamente, quindi viene implementato nel resto dell'infrastruttura.

Il nome deriva dall'abitudine di usare i canarini nelle miniere di carbone come sistema di allerta preventivo. In una distribuzione canary è possibile eseguire test automatizzati e usare gli strumenti di monitoraggio e analisi per ricevere un avviso preventivo di eventuali problemi con la nuova versione all'interno del sottoinsieme di istanze o utenti, In questo modo, l'intero ambiente di produzione non è interessato.

Flag di funzionalità

Il concetto di flag di funzionalità è un'altra strategia che richiede un pizzico di sofisticazione in più da parte degli sviluppatori. Invece di avere due versioni separate dello stesso software (una vecchia e una nuova con nuove funzionalità), si spedirà una singola versione che contiene il comportamento precedente e le nuove modifiche. Le nuove modifiche sono inattive per default e non sono visibili finché non viene attivato il "flag di funzionalità" corrispondente. Un flag può assumere molte forme, tra cui una riga in un file di configurazione, un argomento della riga di comando o un valore recuperato da un servizio di configurazione remoto e valutato in fase di esecuzione.

Un forte vantaggio di questo approccio è la facilità di rollback se si verifica un problema e la facilità di implementazione lenta delle modifiche. In molti casi, non è necessario spedire una nuova versione per esporre o nascondere la funzionalità. È sufficiente disattivare o attivare il flag appropriato e consentire all'applicazione in esecuzione di reagire alla nuova impostazione.

In Azure, la funzionalità di gestione di Configurazione app di Azure fornisce un archivio di flag di funzionalità gestito da cui le applicazioni possono leggere in fase di esecuzione, con il supporto SDK per .NET, Java, Python, JavaScript e Go.

Distribuzioni basate su anello

Una distribuzione basata su anello è una forma strutturata di implementazione progressiva usata ampiamente all'interno di Microsoft e Azure. Il nuovo codice viene rilasciato in una sequenza di "anelli". Ad esempio, un anello interno o dog food, un anello early adopter, un anello di distribuzione ampio e infine un anello di disponibilità generale. Ogni anello è più grande del precedente e la distribuzione passa solo all'anello successivo dopo che i segnali di stato dall'anello corrente soddisfano i criteri definiti. Le distribuzioni basate su anello combinano l'esposizione graduale delle distribuzioni canary con gruppi di destinatari espliciti e denominati e controlli di approvazione tra anelli.

Consegna progressiva

Le strategie precedenti (canary, basate su anelli e flag di funzionalità) sono spesso raggruppate sotto il termine recapito progressivo. L'idea unificante è che una versione venga esposta a un pubblico controllato e in crescita, dotato di metriche di integrità e di business, e avanzato o bloccato automaticamente sulla base di quei segnali. Il recapito progressivo è sempre più il modello predefinito per i servizi cloud ad alta affidabilità perché limita il raggio di esplosione di qualsiasi singola modifica.

Pratiche migliori per la distribuzione

Indipendentemente dalla strategia di distribuzione usata, alcune procedure consigliate consentono di ridurre al minimo i rischi durante l'implementazione di un nuovo software o di una nuova versione del software esistente:

• Usare strumenti appropriati, ad esempio Azure Pipelines o GitHub Actions, per creare una pipeline di integrazione e distribuzione continua.

• Integrare il test automatizzato.

• Usare i canali di comunicazione per informare le parti giuste dei risultati dei test. Ad esempio, avvisare i team quando le distribuzioni hanno esito negativo o riscontrano problemi.

• Monitorare i problemi immediatamente dopo la distribuzione.

• Disporre di un piano per il rollback se una nuova versione non supera i controlli di integrità o funziona correttamente.