Strategia di rilascio Canary contro Blue / Green

La mia comprensione di una versione canary è che è una versione parziale di un sottoinsieme di nodi di produzione con sessioni permanenti attivate. In questo modo puoi controllare e ridurre al minimo il numero di utenti / clienti che subiscono l'impatto se finisci per rilasciare un bug dannoso.

La mia comprensione di una versione blu / verde è che hai 2 ambienti di produzione con mirroring ("blu" e "verde"), e sposti le modifiche a tutti i nodi del blu o del verde contemporaneamente, quindi usi la magia di rete per controllare a quale ambiente vengono indirizzati gli utenti tramite DNS.

Quindi, prima di iniziare, se qualcosa che ho detto finora non è corretto, per favore inizia a correggermi!

Supponendo che io sia più o meno sulla buona strada, allora un paio di domande sulle due strategie:

• Esistono scenari in cui il canarino è preferito al blu / verde e viceversa?
• Esistono scenari in cui un modello di distribuzione può implementare entrambe le strategie contemporaneamente?

Il rilascio blu-verde è più semplice e veloce.

È possibile fare un rilascio blu-verde se aver testato la nuova versione in un ambiente di test e sono molto certi che la nuova versione funzionerà correttamente in produzione. Usando sempre gli interruttori di funzionalità è un buon modo per aumentare la tua fiducia in una nuova versione, poiché la nuova versione funziona esattamente come la vecchia finché qualcuno non attiva un toggle di funzionalità. Suddividere la tua applicazione in piccoli servizi rilasciabili in modo indipendente è un altro, poiché c'è meno da testare e meno da rompere.

È necessario eseguire un rilascio canarino se non si è completamente certi che la nuova versione funzionerà correttamente in produzione. Anche se sei un tester approfondito, Internet è un luogo ampio e complesso e presenta sempre sfide inaspettate. Anche se utilizzi gli interruttori delle funzionalità, uno potrebbe essere implementato in modo errato.

L'automazione della distribuzione richiede impegno, quindi la maggior parte delle organizzazioni pianificherà di utilizzare una strategia o l'altra ogni volta.

Quindi esegui la distribuzione blu-verde se sei impegnato in pratiche che ti consentono di essere sicuro di farlo. Altrimenti, manda fuori il canarino.

L'essenza del blu-verde si sta distribuendo tutto in una volta e l'essenza della distribuzione canary si sta distribuendo in modo incrementale, quindi dato un singolo pool di utenti non riesco a pensare a un processo che descriverei come fare entrambi allo stesso tempo. Se avessi più pool indipendenti di utenti, ad esempio utilizzando diversi data center regionali, potresti fare il blu-verde all'interno di ciascun data center e canary tra i data center. Sebbene se non avessi bisogno della distribuzione canary all'interno di un data center, probabilmente non ne avresti bisogno in tutti i data center.

Ho scritto un saggio dettagliato su questo argomento qui: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

A mio parere, la differenza è se la nuova versione "verde" è esposta o meno agli utenti reali. Se lo è, allora lo chiamerei Canary. Un modo comune per implementare Canary è il normale blu / verde con l'aggiunta del routing intelligente di utenti specifici alla nuova versione. Leggi il post per un confronto dettagliato

Blu verde:

Canarino:

Sebbene entrambi questi termini sembrino abbastanza vicini l'uno all'altro, presentano sottili differenze. Uno mette fiducia nel rilascio della tua funzionalità e l'altro nel modo in cui rilasci.

Canarino

1. La versione canary è una tecnica per ridurre il rischio di introdurre una nuova versione del software in produzione implementando lentamente la modifica a un piccolo sottoinsieme di utenti prima di distribuirla all'intera infrastruttura.

2. Sta per avere un'idea delle prestazioni della nuova versione (integrazione con altre app, CPU, memoria, utilizzo del disco, ecc.).

Blu verde:

1. Riguarda più il rilascio prevedibile con distribuzione senza tempi di inattività.
2. Facile rollback in caso di guasto.
3. Processo di distribuzione completamente automatizzato

Ecco alcune definizioni in linea:

• Distribuzione blu-verde : quando si distribuisce una nuova versione di un'applicazione, viene creato un secondo ambiente. Una volta che il nuovo ambiente è stato testato, prende il posto della vecchia versione. Il vecchio ambiente può quindi essere disattivato.

   

• Test A / B : due versioni di un'applicazione sono in esecuzione contemporaneamente. Una parte delle richieste va a ciascuno. Gli sviluppatori possono quindi confrontare le versioni.  
• Versione Canary : viene avviata una nuova versione di un microservizio insieme alle vecchie versioni. Quella nuova versione può quindi accettare una parte delle richieste e il team può testare come questa nuova versione interagisce con il sistema generale.

Un buon inizio di definizioni. Penso che aiuti anche a prendere una decisione per la tua strategia se dividi la definizione di "rilascio" in "distribuzione" e "rilascio (funzionalità)".

Distribuisci (binari)

L'azione della distribuzione binaria del prodotto in un sistema (di produzione).

Release (funzionalità)

L'azione di gestione della disponibilità di funzionalità per (gruppi di) utenti.

Perché? In genere hai (più) due preoccupazioni quando "rilasci": 1) Bug / compatibilità con le versioni precedenti / ecc. 2) Verifica della validità / usabilità delle nuove funzionalità

Quindi chiedetevi, prima di scegliere una strategia in modalità Canarino o Blu / verde o qualsiasi altra modalità grigia / mista: Quali preoccupazioni abbiamo quando rilasciamo / distribuiamo la nuova versione? E solo allora se conosci le tue preoccupazioni, scegli la tua strategia.

Inoltre, è possibile eseguire strategie di distribuzione / rilascio più complesse. Ad esempio, in alcuni cloud / infra è possibile avere più server di produzione e inoltrare il carico in proporzioni diverse a diversi server e versioni del prodotto e monitorare la solidità prima di ridimensionare un rilascio / distribuzione a tutti gli utenti.

Segnalazione di funzioni

L'azione di "configurazione" (fredda o anche calda) quale funzionalità è (non) disponibile per quale (gruppo) di utenti

Se fai anche qualcosa come il "contrassegno delle funzionalità" puoi prima distribuire, misurare la validità del tuo rilascio in base alla compatibilità con le versioni precedenti / prospettiva dei bug e rilasciare gradualmente nuove funzionalità a diversi utenti, o viceversa (ridimensionare o addirittura ripristinare la funzionalità e / o i file binari ). Il contrassegno delle funzionalità consente di suddividere la disponibilità della funzionalità dalla distribuzione dei file binari e offre un processo decisionale molto più dettagliato rispetto al solo "deploy / rollback"