Che cosa sono i modelli di distribuzione?
Un modello di distribuzione è un approccio automatizzato che consente di distribuire agevolmente nuove funzionalità di un'applicazione agli utenti. Un modello di distribuzione appropriato consente di ridurre al minimo i tempi di inattività. Alcuni modelli consentono inoltre di distribuire nuove funzionalità in modo progressivo. In questo modo, è possibile convalidare nuove funzionalità con utenti selezionati prima di renderle disponibili per tutti.
In questa sezione verranno illustrati alcuni modelli di distribuzione comuni. Si apprenderà anche in che modo il Servizio app di Azure consentirà di implementare il modello scelto dal team di Tailspin.
Riunione del mattino
Il team di Tailspin è ottimista. La pipeline ha accelerato il processo. Il team ha un ambiente di sviluppo in cui è possibile integrare l'app Web con un database. Tim e Amita sono lieti di avere test automatizzati che semplificano il loro lavoro. In generale, riscontrano un numero inferiore di ritardi e di bug.
Esiste però come sempre un problema. Passiamo alla riunione del team. In questo momento ha la parola Tim.
Tim: È così difficile accontentare tutti. Irwin pensa che il rilascio di nuove funzionalità stia richiedendo troppo tempo. Non posso intervenire finché i responsabili del management non approvano la versione e, in questo momento, non esiste un modo semplice per distribuire le funzionalità dopo aver ricevuto l'autorizzazione. Il processo non solo è lungo, ma è anche complicato. Deve essere eseguito manualmente e comporta tempi di inattività. L'intero processo può richiedere cinque giorni. So che è troppo lungo, ma cosa posso fare? Forse se bevo altro caffè, è possibile che mi venga in mente la soluzione.
Andy: Senza dubbio il caffè è fondamentale per la risoluzione dei problemi.
Credo che la soluzione di cui abbiamo bisogno sia un modello di distribuzione valido. Un modello di distribuzione consente di eseguire il cutover in modo automatizzato. È il modo in cui il software passa dalla fase di pre-produzione finale alla produzione vera e propria.
La scelta del modello appropriato può essere sicuramente utile, ad esempio, per ridurre al minimo i tempi di inattività. Un altro vantaggio offerto da un modello di distribuzione è la possibilità di eseguire test che in realtà dovrebbero essere effettuati nell'ambiente di produzione.
Andy inizia a scrivere sulla lavagna.
Ecco le possibilità da prendere in considerazione:
- Distribuzione di tipo blu-verde
- Versioni canary
- Feature toggle
- Lanci al buio
- Test A/B
- Distribuzione con esposizione progressiva
Esaminiamo brevemente ogni modello.
Distribuzioni blu-verde
Una distribuzione blu-verde riduce i rischi e i tempi di inattività eseguendo due ambienti identici. Questi ambienti sono denominati blu e verde. È attivo un solo ambiente per volta. Una distribuzione blu-verde richiede in genere un router o un servizio di bilanciamento del carico per il controllo del flusso del traffico.
Si supponga che sia attivo l'ambiente blu. Durante la preparazione di una nuova versione, i test finali vengono eseguiti nell'ambiente verde. Quando il software è in esecuzione nell'ambiente verde, è sufficiente commutare il router in modo che tutte le richieste in ingresso vengano indirizzate a tale ambiente.
La distribuzione blu-verde consente anche un rapido ripristino dello stato precedente. Se si verificano problemi nell'ambiente verde, è sufficiente riportare il router sull'ambiente blu.
Versioni canary
Una versione canary consente di identificare in anticipo potenziali problemi senza esporre tutti gli utenti al problema. L'idea prevede di esporre una nuova funzionalità solo a un piccolo subset di utenti prima di renderla disponibile per tutti.
In una versione canary viene monitorato cosa avviene quando viene rilasciata la funzionalità. Se la versione presenta problemi, si applica una correzione. Quando la versione canary risulta stabile, viene spostata nell'ambiente di produzione effettivo.
Feature toggle
Usare i feature toggle per "azionare un interruttore" in fase di esecuzione. È possibile distribuire nuovo software senza esporre agli utenti altre funzionalità nuove o modificate.
In questo modello di distribuzione io e Mara compiliamo nuove funzionalità usando un "interruttore". Quando si esegue un rilascio, la funzionalità è "spenta", in modo che non influisca sul software di produzione. A seconda di come viene configurato l'interruttore, è possibile "accenderlo" ed esporre la funzionalità nel modo preferito.
È ad esempio possibile esporre la funzionalità prima di un numero ridotto di utenti per vedere come reagiranno. Questo campione casuale di utenti visualizzerà la funzionalità. In alternativa, è possibile attivare la funzionalità per tutti.
Questo modello di distribuzione tuttavia può risultare vantaggioso per me e Mara più che per altri. Il vantaggio principale del modello di tipo feature toggle è la possibilità di evitare la creazione di un numero eccessivo di rami. Il merge di rami può essere problematico.
Lanci al buio
Un lancio al buio è simile a una versione canary o all'attivazione di un feature toggle. Invece di esporre una nuova funzionalità a tutti, in un lancio al buio la funzionalità viene rilasciata a un piccolo set di utenti.
Questi utenti non sanno che stanno testando la funzionalità. La nuova funzionalità non viene nemmeno evidenziata agli utenti. È per questo motivo che questo modello è denominato lancio al buio. Il software viene rilasciato gradualmente o in modo non intrusivo agli utenti per poter ottenere feedback e testare le prestazioni.
Test A/B
Il test A/B confronta due versioni di una pagina Web o di un'app per determinare quale offre prestazioni migliori. Il test A/B è come un esperimento classico.
Nei test A/B vengono mostrate in modo casuale agli utenti due o più varianti di una pagina. Viene quindi usata l'analisi statistica per decidere quale variante offre prestazioni migliori per i propri obiettivi.
Distribuzione con esposizione progressiva
La distribuzione con esposizione progressiva è talvolta denominata distribuzione basata su anelli. È un altro modo per limitare l'impatto delle modifiche sugli utenti assicurandosi che tali modifiche siano valide in un ambiente di produzione.
Gli anelli sono fondamentalmente un'estensione della fase canary. Le versioni canary stesse vengono rilasciate in un ambiente di staging per misurarne l'effetto. L'aggiunta di un altro anello si basa essenzialmente sullo stesso concetto.
In una distribuzione basata su anelli le modifiche vengono distribuite prima ai clienti con tolleranza al rischio. La distribuzioni viene quindi implementata progressivamente in un set più ampio di clienti.
Implementazione della distribuzione blu-verde
Andy guarda Tim.
Andy: Le considerazioni sono molte, lo so. Volete un po' di tempo per pensarci? Oppure potremmo insieme...
Tim: Blu-verde.
Tutti nella stanza ridono.
Mara: È il caffè a parlare?
Tim: I feature toggle comportano un cambiamento del modo in cui tu e Andy lavorate. Una cosa per volta. I metodi che espongono gradualmente una funzionalità richiedono analisi statistica o feature toggle.
Una distribuzione blu-verde è qualcosa che posso controllare. Commutare un router è semplice. È facile e sembra sicuro. Inoltre, in una distribuzione blu-verde i responsabili del management hanno un ambiente per la valutazione. Quando arriva l'OK, possiamo procedere facilmente. Iniziamo da qui.
Quindi la domanda è: come implementiamo una distribuzione blu-verde nella nostra pipeline?
Che cosa sono gli slot di distribuzione?
Andy: Dal momento che usiamo il Servizio app di Azure, possiamo sfruttare gli slot di distribuzione. Si tratta di app in esecuzione con propri nomi host.
So che non siamo ancora pronti per distribuire il sito Web di Space Game nell'ambiente di produzione come parte della pipeline automatizzata. Possiamo tuttavia aggiungere come test uno slot di distribuzione all'ambiente di gestione temporanea (staging).
Invece di configurare un servizio di bilanciamento del carico o un router, è sufficiente aggiungere un secondo slot all'istanza del servizio app usata nell'ambiente di gestione temporanea (Staging) esistente. Lo slot principale può essere denominato blu e quello secondario verde.
In questo modo è possibile distribuire nuove funzionalità senza tempi di inattività. Scambiamo un'applicazione e la relativa configurazione tra i due slot di distribuzione. In pratica scambiamo gli indirizzi IP dei due slot.
Tim: Mi piace. Questa variante di una distribuzione blu-verde potrebbe essere denominata distribuzione senza tempo di inattività.
Andy: Ottimo! Io e Tim lavoreremo all'implementazione di questo modello di distribuzione. Possiamo incontrarci più avanti per esaminare i risultati.
Suggerimenti per l'uso dei flag funzionalità
I flag funzionalità sono uno dei metodi di frequenza di rilascio presi in considerazione dal team. Il team ha deciso di non usare i flag funzionalità, ma molti utenti li considerano utili. In questa sezione vengono fornite altre informazioni sui flag funzionalità.
I flag funzionalità, noti anche come feature toggle, consentono di modificare il funzionamento di un sistema senza modificare il codice. Questi flag consentono di eseguire il push di nuovo codice nel ramo di sviluppo centrale e fare in modo che venga distribuito, ma non necessariamente reso funzionante. I flag vengono in genere implementati come il valore di variabili che controllano la logica condizionale.
Si supponga che un team stia lavorando nel ramo di sviluppo centrale di un'applicazione bancaria. Si è deciso di eseguire tutto il lavoro nel ramo principale per evitare di dover effettuare operazioni di merge complesse in un secondo momento. Si verifica però un problema. Si stanno apportando modifiche significative ai calcoli degli interessi e gli utenti dipendono ogni giorno da questo codice. A peggiorare la situazione, le modifiche richiederanno settimane. Non è possibile lasciare il codice principale inutilizzabile per un intervallo di tempo così esteso.
In questo scenario l'uso di un flag funzionalità può rivelarsi utile. È possibile modificare il codice in modo che gli utenti per i quali non è stato impostato il flag funzionalità possano continuare a usare il codice originale di calcolo degli interessi. Nel frattempo il team ha impostato il flag funzionalità in modo da poter visualizzare il codice in fase di modifica.
Un altro tipo di flag funzionalità è costituito dal flag di rilascio. Si supponga che, dopo aver completato il lavoro sul codice di calcolo degli interessi, si intenda provarlo prima di rilasciarlo pubblicamente. È disponibile un gruppo di utenti in grado di gestire il nuovo codice e i possibili problemi. Si farà in modo che provino la funzionalità per primi. È possibile modificare la configurazione in modo da impostare per questi utenti il flag funzionalità affinché possano testare il nuovo codice. Se si verificano problemi, potranno disabilitare rapidamente il flag.