Adottare procedure di distribuzione sicure
 Implementare protezioni 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 passano attraverso molte modifiche man mano che vengono implementate e testate e man mano che vengono corretti i bug.
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. La chiave consiste nell'applicare le procedure sicure il prima possibile in modo da avere una prevedibilità nell'ambiente di produzione. Anche se gli errori raggiungono i 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 i voli direttamente tramite l'app. L'app è in esecuzione in produzione da più di un anno.
L'app viene completamente distribuita in Azure ed è basata su servizio app 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 le pipeline. Tutti gli ambienti devono usare pipeline. Classificare asset e versioni per ogni ambiente per renderli facilmente tracciabili e identificabili.
I 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 e dei problemi precedenti 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.
- A causa dell'intervento manuale, ci sono errori frequenti nella distribuzione, rendendo ogni rilascio un evento altamente stressante e dirompente per l'intero team. L'intervento manuale rende anche difficile il rollback quando una distribuzione non riesce.
Applicazione dell'approccio e dei 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 che vengono salvati nel controllo del codice sorgente per una tracciabilità aggiuntiva. Impostazioni considerati segreti vengono salvati in archivi dell'insieme di credenziali dei segreti, allocati anche a ogni 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 per ottimizzare ulteriormente i processi.
- In seguito alla nuova automazione, le distribuzioni sono state più affidabili e prevedibili e anche il morale del team è aumentato.
Distribuire spesso
Distribuire piccoli aggiornamenti incrementali a cadenza regolare.
L'uso di questo approccio consente di mantenere gestibili le storie utente 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
- I processi di distribuzione del team storicamente hanno dovuto eseguire versioni principali ogni tre o quattro mesi. Questa procedura rende difficile convalidare la versione. Il team ha anche avuto difficoltà a risolvere i problemi relativi a tante parti in movimento.
- Le versioni problematiche che richiedono correzioni a caldo di rilascio intermedie o che devono essere ripristinate e abbandonate sono state eseguite più volte.
- I rilasci sono altamente stressanti e sono stati trattati come situazioni "tutte le mani sul ponte", che ha avuto un impatto negativo sul morale del team.
Applicazione dell'approccio e dei risultati
- Dopo la versione più recente problematica, gli stakeholder hanno chiesto al team di adottare un approccio migliore alle distribuzioni. Il team ha deciso di modificare le proprie pratiche per favorire modifiche frequenti e piccole. Limiteranno l'ambito di ogni versione a una o (al massimo) ad alcune modifiche correlate testate accuratamente man mano che la compilazione viene alzata di livello negli ambienti inferiori.
- Di conseguenza, le versioni sono diventate molto più efficienti e la qualità è aumentata. Le versioni sono più facili da convalidare e i problemi sono più semplici da risolvere.
- Avere una cadenza regolare di rilasci prevedibili ha contribuito a ripristinare la fiducia e il morale del team. Anche gli utenti traggono vantaggio. Con una qualità di rilascio superiore, vedono meno interruzioni e ottengono l'accesso alle nuove funzionalità molto prima.
Usare un approccio di esposizione progressiva
Implementare gli aggiornamenti gradualmente, con due diligence. Usare i modelli di distribuzione che offrono il controllo per aumentare progressivamente il numero di istanze e clienti fino a quando l'aggiornamento non viene adottato in modo sicuro da tutti.
Testare ogni aggiornamento in modo controllato in modo che i problemi vengano risolti all'inizio della produzione. Evitare di distribuire un aggiornamento difettoso che influisce sull'intera base clienti.
Verificare se l'aggiornamento è compatibile con le versioni precedenti e successive.
Sfida di Contoso
- Il team sta vedendo grandi vantaggi dal cambio di approccio per rendere più piccole le versioni. Si dedicano meno tempo ora alle versioni e si sentono eccitati per continuare il percorso di apportare ulteriori miglioramenti dell'eccellenza operativa.
- Quando sperimentano nuove funzionalità, alcune delle modifiche non sono state ben ricevute dagli utenti o hanno causato un aumento delle chiamate di supporto a causa della curva di apprendimento ripida che portano avanti.
- Si chiede come continuare a innovare le applicazioni per ottimizzare la produttività dell'utente, riducendo al minimo l'impatto del rilascio di funzionalità che potrebbero non essere così popolari o facili da usare.
Applicazione dell'approccio e dei risultati
- Hanno deciso di implementare un modello di versione delle funzionalità che espone le nuove funzionalità agli utenti in modo incrementale, usando i flag di funzionalità.
- Durante le fasi di pianificazione per le nuove funzionalità, viene definito un criterio per selezionare gli utenti che verranno prima esposti alla funzionalità. Per prima cosa viene selezionato un piccolo gruppo di utenti per ricevere la nuova funzionalità. A seconda del feedback degli utenti, la funzionalità viene distribuita in gruppi di dimensioni successive fino a quando l'intero popolamento utente non esegue la nuova versione. Man mano che più utenti sono esposti alle nuove funzionalità, il team di supporto documenta il risultato dei casi di supporto per condividere internamente e potenzialmente popolare le domande frequenti esterne.