Adottare procedure di distribuzione sicure
 Implementare guardrail nel processo di distribuzione per ridurre al minimo l'effetto di errori o condizioni impreviste. |
|---|
Durante il ciclo di sviluppo, gli artefatti del carico di lavoro subiscono molte modifiche man mano che vengono implementati e testati e man mano che i bug vengono corretti.
Il processo di distribuzione deve seguire una procedura operativa standard. Qualsiasi modifica deve essere distribuita con lo stesso livello di rigore. Questo principio si applica allo stesso modo al codice, alla configurazione e a tutti gli artefatti correlati. Il principio fondamentale consiste nell'applicare le procedure sicure il prima possibile in modo da avere prevedibilità nell'ambiente di produzione. Anche se gli errori dovessero arrivare ai clienti, dovrebbe essere possibile implementare le modifiche di ripristino il prima possibile.
Scenario di esempio
Contoso Air ha sviluppato un'applicazione Web che consente al cliente di prenotare voli direttamente tramite l'app. L'app è in esecuzione in produzione da più di un anno.
L'app viene distribuita completamente in Azure ed è basata su Servizio app di Azure, Azure Cosmos DB, Funzioni di Azure, App per la logica di Azure e bus di servizio di Azure.
Codificare gli standard di distribuzione automatizzata
Standardizzare il processo per distribuire qualsiasi modifica usando processi di distribuzione automatizzati, ad esempio pipeline. Tutti gli ambienti devono usare pipeline. Classificare asset e versioni per ogni ambiente per renderli facilmente tracciabili e identificabili.
Metodi di distribuzione coerenti riducono i problemi causati da errori di processo e varianza e consentono di concentrarsi sulle problematiche del carico di lavoro.
La standardizzazione garantisce che la distribuzione venga completata in modo sicuro, affidabile e ripetibile.
La classificazione semplifica la visualizzazione dei log delle distribuzioni precedenti e di problemi che si sono verificati. È possibile usare tali informazioni per accelerare le operazioni di rollback e rollforward.
Sfida di Contoso
- Il team del carico di lavoro Contoso Air usa pipeline di compilazione e distribuzione automatizzate, ma le distribuzioni richiedono in genere un intervento manuale durante l'operazione per modificare e convalidare varie impostazioni di configurazione.
- L'intervento manuale causa errori frequenti nella distribuzione, rendendo ogni rilascio un evento altamente stressante e distruttivo per l'intero team. L'intervento manuale rende anche difficile eseguire il rollback quando una distribuzione non riesce.
Applicazione dell'approccio e risultati
- Il team alloca il tempo necessario per automatizzare le modifiche di configurazione come parte della distribuzione e per integrare le funzionalità aggiunte nelle pipeline di distribuzione esistenti.
- Le impostazioni di configurazione associate a ogni ambiente vengono esternalizzate ai rispettivi file JSON, i quali vengono salvati nel controllo del codice sorgente per maggiore tracciabilità. Le impostazioni considerate segreti vengono salvate negli archivi dell'insieme di credenziali dei segreti, i quali sono allocati anche a ciascun ambiente.
- Tutte le modifiche vengono ora registrate durante la distribuzione, ottenendo una tracciabilità completa per facilitare le attività di risoluzione dei problemi e i controlli. Il team aggiunge anche test automatizzati per convalidare le modifiche di configurazione alla pipeline.
- Successivamente, il team lavorerà per automatizzare completamente i rollback al dine di ottimizzare ulteriormente i processi.
- In seguito alla nuova automazione, le distribuzioni sono risultate più affidabili e prevedibili e anche il morale del team è migliorato.
Distribuire spesso
Distribuire piccoli aggiornamenti incrementali a cadenza regolare.
L'uso di questo approccio consente di mantenere gestibili le storie degli utenti e gli elementi di lavoro dal punto di vista della gestione dei progetti e ridurre il rischio di problemi su larga scala quando le distribuzioni hanno esito negativo.
Sfida di Contoso
- In passato, i processi di distribuzione del team dovevano eseguire rilasci principali ogni tre o quattro mesi. Questa procedura rende difficile convalidare il rilascio. Il team aveva anche difficoltà a risolvere problemi a causa di tante parti in movimento.
- Rilasci problematici che richiedono correzioni a caldo durante il rilascio o per cui deve essere eseguito il rollback e quindi essere abbandonati si sono presentati in più occasioni.
- I rilasci sono altamente stressanti e sono stati trattati come situazioni che richiedono "tutti ai posti di combattimento", il che ha avuto un impatto negativo sul morale del team.
Applicazione dell'approccio e risultati
- Dopo il rilascio problematico più recente, gli stakeholder hanno chiesto al team di adottare un approccio migliore alle distribuzioni. Il team ha deciso di modificare le proprie procedure per favorire modifiche frequenti e di piccole dimensioni. Limiteranno l'ambito di ogni rilascio a una o (al massimo) alcune modifiche correlate testate accuratamente man mano che la compilazione viene promossa tra gli ambienti di livello inferiore.
- Grazie a ciò, i rilasci sono diventati molto più efficienti e la qualità è migliorata. I rilasci sono più facili da convalidare e i problemi sono più semplici da risolvere.
- L'esecuzione di rilasci prevedibili a cadenza regolare ha contribuito a ristabilire la fiducia e il morale del team. Anche gli utenti ne beneficiano. Con una qualità di rilascio superiore, devono affrontare meno interruzioni e ottengono accesso alle nuove funzionalità molto prima.
Usare un approccio a esposizione progressiva
Implementare gli aggiornamenti gradualmente, con due diligence. Usare modelli di distribuzione che permettano di aumentare progressivamente il numero di istanze e clienti fino a quando l'aggiornamento non viene adottato da tutti in sicurezza.
Testare ogni aggiornamento in modo controllato in modo che i problemi vengano risolti all'inizio della produzione. Evitare di distribuire un aggiornamento difettoso che incide sull'intera base clienti.
Verificare se l'aggiornamento sia compatibile con le versioni precedenti e successive.
Sfida di Contoso
- Il team sta riscontrando grandi vantaggi nel cambio di approccio a rilasci più piccoli. Ora che devono dedicare meno tempo ai rilasci, i membri del team hanno le energie per continuare ad apportare miglioramenti di eccellenza operativa.
- Mentre il team sperimenta con nuove funzionalità, alcune delle modifiche non sono state ben ricevute dagli utenti o hanno causato un aumento delle chiamate di assistenza a causa della ripida curva d'apprendimento ad esse associata.
- I membri del team si domandano come continuare a innovare le proprie applicazioni per ottimizzare la produttività dell'utente, riducendo al tempo stesso al minimo l'impatto del rilascio di funzionalità che potrebbero non essere così popolari o facili da usare.
Applicazione dell'approccio e risultati
- Hanno deciso di implementare un modello di release funzionale che rivela le nuove funzionalità agli utenti in modo incrementale, usando flag di funzionalità.
- Durante le fasi di pianificazione per nuove funzionalità, viene definito un criterio per selezionare gli utenti che verranno esposti per primi alla funzionalità. Viene selezionato un piccolo gruppo di utenti che riceveranno per primi la nuova funzionalità. A seconda del feedback degli utenti, la funzionalità viene distribuita in gruppi di dimensioni progressivamente maggiori fino a quando l'intera popolazione di utenti non usa la nuova versione. Man mano che più utenti sono esposti alle nuove funzionalità, il team di supporto documenta il risultato dei casi di assistenza per condividere internamente e potenzialmente popolare le domande frequenti esterne.