Adottare procedure di distribuzione sicure

Mettere in atto protezioni durante il processo di distribuzione per ridurre l'impatto di errori o condizioni impreviste.

Configurare un processo di distribuzione modulare automatizzato in modo che tutto venga distribuito allo stesso modo ogni volta. Quando si applicano procedure sicure in anticipo, ad esempio nei test, nel monitoraggio e nel controllo delle versioni, si crea fiducia nell'ambiente di produzione e si semplifica il ripristino in caso di problemi.

Scenario di esempio

Contoso Air ha sviluppato un'applicazione Web che consente al cliente di prenotare direttamente i voli. 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.

Distribuire l'infrastruttura tramite codice

Usare l'infrastruttura come codice (IaC) per definire gli aspetti ripetibili della supply chain pronti per la produzione. Preferisce approcci dichiarativi rispetto ai metodi imperativi.

Gli strumenti IaC dichiarativi sono creati per semplificare l'automazione e il riutilizzo. Consentono di spostare la configurazione dell'infrastruttura da utenti singoli a strumenti e pipeline, in modo che le azioni vengano eseguite allo stesso modo ogni volta, con un minor numero di errori.

Un minor numero di opzioni tecnologico riduce anche la varianza degli strumenti, semplifica la visualizzazione della deriva della configurazione e semplifica la manutenzione. Se si selezionano strumenti che corrispondono alle competenze esistenti del team, è più facile per tutti essere a bordo.

Sfida di Contoso

• Il team del carico di lavoro Contoso Air usa pipeline di compilazione e distribuzione automatizzate, ma in genere devono eseguire manualmente il passaggio durante il processo per modificare e controllare impostazioni di configurazione diverse.

• A causa di tutto il lavoro manuale, gli errori di distribuzione si verificano spesso. Ogni rilascio è un evento stressante e dirompente per l'intero team. E quando una distribuzione ha esito negativo, il rollback non è neanche facile.

Applicazione dell'approccio e dei risultati

• Il team ha messo da parte il tempo per automatizzare le modifiche di configurazione come parte della distribuzione e per aggiungere le nuove funzionalità nelle pipeline di distribuzione esistenti.

• Le impostazioni di configurazione per ogni ambiente vengono ora archiviate in file JSON separati, che vengono salvati nel controllo del codice sorgente in modo che siano facili da tenere traccia. Tutte le impostazioni considerate segreti vengono archiviate negli insiemi di credenziali dei segreti, con una configurazione per ogni ambiente.

• Ogni modifica viene ora registrata durante la distribuzione, fornendo la tracciabilità completa per facilitare la risoluzione dei problemi e i controlli. Il team aggiunge anche test automatizzati alla pipeline per verificare che le modifiche alla configurazione funzionino come previsto.

• Successivamente, il team prevede di automatizzare completamente i rollback per rendere il processo ancora più uniforme.

• In seguito alla nuova automazione, le distribuzioni sono state più affidabili e prevedibili e anche il morale del team è salito.

Distribuire aggiornamenti incrementali di piccole dimensioni a cadenza regolare

Dividere il lavoro in piccoli aggiornamenti gestibili che possono essere sviluppati e distribuiti frequentemente.

Gli aggiornamenti più piccoli sono più facili da testare e meno rischiosi. Se si verifica un errore, è più facile trovare e correggere. Il rilascio di diverse modifiche in una sola volta può causare problemi più grandi e rendere più difficile capire cosa è andato storto.

Sfida di Contoso

• Il team ha usato per eseguire le versioni principali ogni tre-quattro mesi, che ha reso difficile convalidare tutto correttamente. Con così tante parti in movimento, la risoluzione dei problemi è stata una vera sfida.

• Ci sono state diverse versioni approssimative che richiedevano correzioni a caldo midstream o doveva essere eseguito completamente il rollback.

• Ogni rilascio si è trasformato in una situazione che richiedeva l'aiuto di tutti. Erano molto stressanti e svuotamento per tutta la squadra, che ha davvero preso un pedaggio sul morale.

Applicazione dell'approccio e dei risultati

• Dopo la versione più recente problematica, gli stakeholder hanno chiesto al team di ripensare il modo in cui gestiscono le distribuzioni. Il team ha deciso di cambiare marcia e andare con cambiamenti più piccoli e più frequenti. Ogni versione si concentrerà ora solo su uno o su alcuni aggiornamenti strettamente correlati che vengono testati accuratamente durante lo spostamento negli ambienti inferiori.

• Questa modifica ha reso le versioni più efficienti e la qualità è aumentata. È più facile convalidare ogni versione e tenere traccia dei problemi è molto più semplice.

• Un ritmo costante di rilasci prevedibili ha davvero aiutato a ripristinare il morale e la fiducia del team. Gli utenti riscontrano anche i vantaggi, con un minor numero di interruzioni e un accesso più rapido alle nuove funzionalità.

Usare un approccio di esposizione progressiva

Implementare gli aggiornamenti gradualmente e con attenzione. Usare i modelli di distribuzione che consentono di iniziare lentamente a partire da poche istanze o clienti, in modo da garantire che gli aggiornamenti funzionino senza problemi prima di procedere tutti.

Testare ogni aggiornamento in modo controllato in modo da poter rilevare e risolvere i problemi nelle prime fasi dell'ambiente di produzione. Questa procedura consente di evitare il push di un aggiornamento difettoso che potrebbe influire su tutti i clienti.

Verificare se l'aggiornamento è compatibile con le versioni precedenti e successive per verificare se funziona bene con altre versioni.

Sfida di Contoso

• Il team sta vedendo alcuni grandi vantaggi dal passaggio a versioni più piccole. Si dedicano meno tempo alla gestione delle distribuzioni e si sentono motivati a continuare a eseguire il push per migliorare il modo in cui vengono eseguiti i processi.

• Ma mentre provano nuove funzionalità, non tutto è atterrato bene. Alcune modifiche hanno confuso gli utenti o hanno portato a più chiamate di supporto a causa di curve di apprendimento ripide.

• Ora stanno pensando a come mantenere l'innovazione in modi che migliorano davvero la produttività degli utenti, senza causare troppe interruzioni quando una nuova funzionalità potrebbe non essere così popolare o facile da usare.

Applicazione dell'approccio e dei risultati

• Il team ha deciso di implementare gradualmente nuove funzionalità usando i flag di funzionalità, in modo che gli utenti ottengano l'accesso alle nuove funzionalità in modo incrementale.

• Durante la pianificazione, definiscono chi dovrebbe prima visualizzare la funzionalità. In genere un piccolo gruppo di utenti ottiene l'accesso anticipato. In base alla modalità di risposta del gruppo, il team espande l'implementazione a più utenti fino a quando tutti non hanno la nuova versione. Man mano che più persone iniziano a usare le funzionalità, il team di supporto tiene traccia di ciò che accade nei casi di supporto e condivide tali informazioni internamente e possibilmente anche nelle domande frequenti esterne.