Riepilogo
In questo modulo, è stato definito un modello di distribuzione come un modo automatizzato per distribuire agevolmente nuove funzionalità di un'applicazione agli utenti. Un modello di distribuzione valido può contribuire a ridurre al minimo i tempi di inattività. Consente inoltre di distribuire nuove funzionalità agli utenti in modo progressivo.
Puoi scegliere tra diversi modelli di distribuzione. Il modello di distribuzione scelto dipende dai motivi della distribuzione e dalle risorse. Sono disponibili tester canary? Si userà un lancio al buio e si sceglieranno tester che non saranno a conoscenza di essere scelti come tester? Se disponi di un set di tester attendibile che aumenta progressivamente da un set di dimensioni ridotte a uno più grande, è possibile scegliere una distribuzione con esposizione progressiva. Se invece si vuole verificare se una versione offre prestazioni migliori rispetto a un'altra versione, è possibile scegliere un test A/B.
Il team di Tailspin ha scelto di implementare il modello di distribuzione blu verde usando gli slot di distribuzione nel servizio app di Azure. Gli slot di distribuzione sono app dinamiche con propri nomi host. Il team può scambiare due slot di distribuzione. Mediante lo scambio puoi promuovere immediatamente le modifiche all'ambiente di produzione. Sebbene il team non sia ancora pronto a rilasciare il proprio sito Web al pubblico, ha dimostrato di poter offrire nuove funzionalità per gli utenti senza incorrere in tempi di inattività.
In questo modulo hai anche appreso come eseguire il roll forward di una modifica accidentale annullando un commit Git, quindi eseguendo attraverso la pipeline il push della modifica annullata.
In che modo si sta adeguando il team?
Nel modulo Valutazione del processo di sviluppo software esistente, Mara ha eseguito un esercizio di mapping del flusso di valori. L'esercizio ha consentito al team di analizzare il processo del ciclo di rilascio corrente.
Tieni presente che il rapporto di attività, o efficienza, corrisponde al tempo di elaborazione diviso per il lead time totale:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
Il team Web di Tailspin ha inizialmente usato questa metrica e ha determinato un'efficienza del 23%.
Il team ha prima ridotto alcune inefficienze con l'implementazione dell'integrazione continua (CI). Applicando la distribuzione continua (CD), le inefficienze sono state ulteriormente ridotte.
Nei percorsi di apprendimento precedenti il team ha ridotto:
Il tempo necessario per configurare il controllo del codice sorgente per le nuove funzionalità. Il tempo necessario è passato da tre giorni a zero giorni.
Il team ha ottenuto questo miglioramento passando dal controllo del codice sorgente centralizzato a Git, un tipo di controllo del codice sorgente distribuito. Usando il controllo del codice sorgente distribuito, non è necessario attendere lo sblocco dei file.
Il tempo necessario per distribuire il codice ad Amita, che ricopre il ruolo di tester. Il tempo necessario è passato da due giorni a zero giorni.
Il team ha ottenuto questo miglioramento spostando il processo di compilazione in Azure Pipelines. Azure Pipelines informa automaticamente Amita quando è disponibile una compilazione. Gli sviluppatori non devono più aggiornare il foglio di calcolo di Amita per inviarle la notifica.
Il tempo impiegato da Amita per testare le nuove funzionalità. Il tempo necessario è passato da tre giorni a un giorno.
Il team ha ottenuto questo miglioramento eseguendo il test unità del codice. L'esecuzione del test unità avviene ogni volta che una modifica attraversa la pipeline di compilazione. In questo modo Amita ottiene codice con meno bug e regressioni. Grazie al carico di lavoro ridotto, Amita può completare ogni test manuale più velocemente.
La pipeline di versione creata con il team in questo percorso di apprendimento ha ridotto:
Il tempo necessario per il passaggio della compilazione alla fase Test. Il tempo necessario è passato da tre giorni a un giorno.
Il team ha ottenuto questo risultato usando un trigger pianificato per eseguire la distribuzione nella fase Test ogni giorno alle 3.00.
Il tempo necessario per il passaggio della compilazione testata alla fase di gestione temporanea (Staging). Il tempo necessario è passato da due giorni a zero giorni.
Il team ha ottenuto questo miglioramento aggiungendo alla fase Test i test Selenium dell'interfaccia utente, un tipo di test funzionali. Questi test automatizzati sono molto più veloci rispetto alle versioni manuali.
Il tempo necessario per il passaggio della compilazione approvata dalla fase di gestione temporanea (Staging) alla modalità attiva. Il tempo necessario è passato da un giorno a meno di un giorno.
Il team ha ottenuto questo miglioramento aggiungendo controlli di approvazione manuali alla pipeline. Quando i responsabili del management si disconnettono, Tim può rilasciare le modifiche dalla fase di gestione temporanea (Staging) alla modalità attiva.
Queste modifiche consentono di ridurre il lead time totale da 22 giorni a 10 giorni. Sostituendo questi numeri nell'equazione si ottiene:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{10\ days}}{ = 0.50}$$
Moltiplicando il risultato per il 100% si ottiene una riduzione del 50%.
Anche se esiste sempre spazio per migliorare, questa modifica costituisce una vittoria per il team. Non solo i clienti ottengono valore più rapidamente, ma il team di Tailspin ora è soggetto a un minore tempo di attesa e dispone pertanto di più tempo per dedicarsi all'attività preferita, ovvero la distribuzione di funzionalità che verranno apprezzate dai clienti.
Altre informazioni
Usa queste risorse aggiuntive per ottenere altre informazioni sul servizio app, sugli slot di distribuzione e sul rollback delle modifiche: