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 implementata in più fasi entro un determinato periodo di tempo, aumentando gradualmente le istanze del nuovo codice e riducendo al tempo stesso quelle del precedente. Ciò significa che le nuove istanze e quelle precedenti coesisteranno all'interno dell'organizzazione. Ad esempio, è possibile aggiornare il software in un server, in una macchina virtuale o in 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 distinti identici tra loro. Uno è un ambiente di test contenente la nuova versione del software, l'altro è l'ambiente di produzione corrente. Quando si è soddisfatti del funzionamento del software e se rispetta gli standard, è possibile eseguire un passaggio completo dall'ambiente di produzione corrente a quello nuovo, in modo che gestisca l'intero traffico di produzione.
L'ambiente blu è l'ambiente di produzione corrente. L'ambiente verde è un duplicato esatto. Per prima cosa si distribuisce la nuova versione del software nell'ambiente verde, quindi quando si è pronti si instrada il traffico dell'applicazione dall'ambiente blu a quello verde, che è diventato l'ambiente di produzione.
Uno dei vantaggi di questa strategia è che è possibile rendere il passaggio quasi istantaneo, senza tempi di inattività. È anche facile tornare all'ambiente blu se si verifica un problema dopo essere passati a quello verde.
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 implica una maggiore complessità per gli sviluppatori. Anziché disporre di due versioni distinte dello stesso software, una vecchia e una nuova (presumibilmente con nuove funzionalità), viene fornita una versione del software che contiene sia il software precedente sia le nuove modifiche (funzionalità e così via). Le nuove modifiche sono inattive per impostazione predefinita e non sono visibili fino a quando non viene attivato il "flag di funzionalità" per la modifica. Il flag può assumere forme diverse, ad esempio una riga in un file di configurazione, un argomento della riga di comando, una risposta speciale di un server online che il software consulta all'avvio e così via.
Un indiscutibile vantaggio di questo approccio è la facilità con cui è possibile eseguire il rollback in caso di problemi o implementare lentamente le modifiche. Non è necessario inviare una nuova versione (con tutti i relativi bit) a server e clienti, è sufficiente disattivare o attivare il flag appropriato per effettuare il downgrade o l'aggiornamento.
Procedura consigliate per la distribuzione
Indipendentemente dalla strategia di distribuzione adottata, esistono alcune procedure consigliate che consentono di ridurre al minimo i rischi durante l'implementazione di nuovo software o di una nuova versione del software esistente:
Usare gli strumenti appropriati, come Azure Pipelines, per creare una pipeline per l'integrazione e la distribuzione continue.
Integrare il test automatizzato.
Usare i canali di comunicazione per notificare alle parti appropriate i risultati dei test, ovvero avvisare i team se le distribuzioni non riescono, si verificano problemi e così via.
Monitorare i problemi immediatamente dopo la distribuzione.
Disporre di un piano per il rollback se la distribuzione di una nuova versione non supera i controlli di integrità o non funziona correttamente.