Procedure di distribuzione sicure

A volte una versione non dipende da aspettative. Nonostante l'uso di procedure consigliate e il superamento di tutti i controlli di qualità, si verificano occasionalmente problemi che causano problemi imprevisti per gli utenti. Per ridurre al minimo e ridurre l'impatto di questi problemi, i team DevOps sono invitati ad adottare una strategia di esposizione progressiva che bilancia l'esposizione di una determinata versione con le sue prestazioni comprovate. Come versione dimostra se stessa nell'ambiente di produzione, diventa disponibile per i livelli di destinatari più ampi fino a quando tutti non lo usano. Teams può usare procedure di distribuzione sicure per ottimizzare la qualità e la velocità delle versioni nell'ambiente di produzione.

Controllare l'esposizione ai clienti

I team DevOps possono usare varie procedure per controllare l'esposizione degli aggiornamenti ai clienti. Storicamente, i test A/B sono stati una scelta popolare per i team che cercano di vedere come le diverse versioni di un servizio o dell'interfaccia utente eseguano rispetto agli obiettivi di destinazione. I test A/B sono anche relativamente facili da usare poiché le modifiche sono in genere minori e spesso confrontano solo versioni diverse al bordo del cliente di un servizio.

Cassaforte distribuzione tramite anelli

Man mano che le piattaforme aumentano, anche la scalabilità dell'infrastruttura e le esigenze dei destinatari tendono a crescere. In questo modo si crea una richiesta di un modello di distribuzione che bilancia i rischi associati a una nuova distribuzione con i vantaggi degli aggiornamenti che promette. L'idea generale è che una determinata versione deve essere esposta solo a un piccolo gruppo di utenti con la massima tolleranza per il rischio. Quindi, se la versione funziona come previsto, può essere esposta a un gruppo più ampio di utenti. Se non ci sono problemi, il processo può continuare attraverso gruppi più ampi di utenti o anelli, fino a quando tutti non usano la nuova versione. Con le moderne piattaforme di recapito continuo come GitHub Actions e Azure Pipelines, la creazione di un processo di distribuzione con anelli è accessibile ai team DevOps di qualsiasi dimensione.

Flag di funzionalità

Alcune funzionalità a volte devono essere distribuite come parte di una versione, ma non inizialmente esposte agli utenti. In questi casi, i flag di funzionalità forniscono una soluzione in cui le funzionalità possono essere abilitate tramite modifiche di configurazione in base all'ambiente, all'anello o a qualsiasi altra distribuzione specifica.

Consenso esplicito dell'utente

Analogamente ai flag di funzionalità, il consenso esplicito dell'utente consente di limitare l'esposizione. In questo modello, una determinata funzionalità è abilitata nella versione, ma non è attivata per un utente, a meno che non lo desideri in modo specifico. La decisione di tolleranza al rischio viene scaricata agli utenti in modo che possano decidere quanto rapidamente vogliono adottare determinati aggiornamenti.

Più pratiche vengono comunemente impiegate contemporaneamente. Ad esempio, un team può avere una funzionalità sperimentale destinata a un caso d'uso molto specifico. Poiché è rischioso, lo distribuiranno nel primo anello per gli utenti interni da provare. Tuttavia, anche se le funzionalità si trovano nel codice, un utente dovrà impostare il flag di funzionalità per una distribuzione specifica all'interno dell'anello in modo che la funzionalità venga esposta tramite l'interfaccia utente. Anche in questo caso, il flag di funzionalità può esporre solo l'opzione per consentire a un utente di acconsentire esplicitamente all'uso della nuova funzionalità. Chiunque non sia presente nell'anello, su tale distribuzione o non abbia acconsentito esplicitamente non verrà esposto alla funzionalità. Anche se si tratta di un esempio abbastanza contrived, serve a illustrare la flessibilità e la praticità dell'esposizione progressiva.

Problemi comuni che i team affrontano in anticipo

Man mano che i team si spostano verso una pratica più Agile DevOps, possono riscontrare problemi coerenti con gli altri utenti che hanno eseguito la migrazione da consegne monolitiche tradizionali. I team usati per la distribuzione una volta ogni pochi mesi hanno una mentalità orientata al buffer per la stabilizzazione. Si prevede che ogni distribuzione introduca un notevole cambiamento nel servizio e che ci saranno problemi imprevisti.

I payload sono troppo grandi

I servizi distribuiti ogni pochi mesi vengono in genere riempiti con molte modifiche. Ciò aumenta la probabilità che ci saranno problemi immediati e rende anche difficile risolvere tali problemi poiché c'è tanta roba nuova. Passando a consegne più frequenti, le differenze di ciò che viene distribuito diventano più piccole, consentendo test più mirati e debug più semplice.

Nessun isolamento del servizio

I sistemi monolitici vengono tradizionalmente ridimensionati livellando l'hardware in cui vengono distribuiti. Tuttavia, quando qualcosa va storto con l'istanza, porta a problemi per tutti. Una soluzione semplice consiste nell'aggiungere più istanze in modo da poter bilanciare il carico degli utenti. Tuttavia, questo può richiedere considerazioni significative sull'architettura, poiché molti sistemi legacy non vengono compilati per essere multiistanza. Inoltre, potrebbe essere necessario allocare risorse duplicate significative per le funzionalità che potrebbero essere consolidate meglio altrove.

Man mano che vengono aggiunte nuove funzionalità, esaminare se un'architettura di microservizi può essere utile per operare e ridimensionare grazie a un migliore isolamento del servizio.

I passaggi manuali causano errori

Quando un team distribuisce solo alcune volte all'anno, l'automazione delle consegne potrebbe non sembrare valsa la pena di investire. Di conseguenza, molti processi di distribuzione vengono gestiti manualmente. Ciò richiede una quantità significativa di tempo e sforzo ed è soggetto a errori umani. È sufficiente automatizzare le attività di compilazione e distribuzione più comuni per ridurre il tempo perso e gli errori non forzati.

Teams può anche usare l'infrastruttura come codice per avere un controllo migliore sugli ambienti di distribuzione. In questo modo si elimina la necessità di richieste al team operativo di apportare modifiche manuali man mano che vengono introdotte nuove funzionalità o dipendenze in vari ambienti di distribuzione.

Solo Ops può eseguire distribuzioni

Alcune organizzazioni dispongono di criteri che richiedono l'avvio e la gestione di tutte le distribuzioni da parte del personale operativo. Anche se in passato ci sono stati buoni motivi, un processo Agile DevOps offre vantaggi molto utili quando il team di sviluppo può avviare e controllare le distribuzioni. Le moderne piattaforme di recapito continuo offrono un controllo granulare su chi può avviare le distribuzioni e chi può accedere ai log di stato e ad altre informazioni di diagnostica, assicurandosi che le persone giuste abbiano le informazioni corrette il più rapidamente possibile.

Continuare le distribuzioni non riuscite e non è possibile eseguire il rollback

A volte una distribuzione va storta e i team devono risolverlo. Tuttavia, quando i processi sono manuali e l'accesso alle informazioni è lento e limitato, può essere difficile eseguire il rollback a una distribuzione funzionante precedente. Fortunatamente, esistono diversi strumenti e procedure per ridurre il rischio di distribuzioni non riuscite.

Principi di base

I team che cercano di adottare procedure di distribuzione sicure devono impostare alcuni principi di base per sostenere lo sforzo.

Essere coerenti

Gli stessi strumenti usati per la distribuzione nell'ambiente di produzione devono essere usati negli ambienti di sviluppo e test. In caso di problemi, ad esempio quelli che spesso derivano da nuove versioni di dipendenze o strumenti, devono essere rilevati bene prima che il codice venga rilasciato all'ambiente di produzione.

Attenzione ai segnali di qualità

Troppi team rientrano nella trappola comune di non preoccuparsi veramente dei segnali di qualità. Nel corso del tempo, possono scoprire che scrivono test o eseguono attività di qualità semplicemente per modificare un avviso giallo in un'approvazione verde. I segnali di qualità sono davvero importanti perché rappresentano l'impulso di un progetto. I segnali di qualità usati per approvare le distribuzioni devono essere monitorati costantemente ogni giorno.

Le distribuzioni devono richiedere tempi di inattività pari a zero

Anche se non è fondamentale che ogni servizio sia sempre disponibile, i team devono affrontare le fasi operative e di distribuzione devOps con la mentalità che possono e devono distribuire nuove versioni senza doverli arrestare per qualsiasi momento. L'infrastruttura moderna e gli strumenti di pipeline sono abbastanza avanzati ora dove è possibile praticamente per qualsiasi team raggiungere il tempo di attività del 100%.

Le distribuzioni devono essere eseguite durante l'orario di lavoro

Se un team collabora con la mentalità che le distribuzioni richiedono tempi di inattività zero, non è importante quando viene eseguito il push di una distribuzione. Inoltre, diventa vantaggioso effettuare il push delle distribuzioni durante l'orario di lavoro, soprattutto all'inizio del giorno e all'inizio della settimana. Se qualcosa va storto, dovrebbe essere tracciato abbastanza presto per controllare il raggio dell'esplosione. Inoltre, tutti stanno già lavorando e incentrati sul recupero dei problemi risolti.

Distribuzione basata su circuito

I team con procedure di rilascio DevOps mature sono in grado di assumere la distribuzione basata su circuito. In questo modello, le nuove funzionalità vengono prima implementate ai clienti disposti ad accettare il maggior rischio. Man mano che la distribuzione è comprovata, il gruppo di destinatari si espande per includere più utenti fino a quando non viene usato da tutti.

Modello circolare di esempio

Un tipico modello di distribuzione circolare è progettato per individuare i problemi il prima possibile tramite l'attenta segmentazione degli utenti e dell'infrastruttura. L'esempio seguente illustra come gli anelli vengono usati da un team principale di Microsoft.

Anello Scopo Utenti Centro dati
0 Trova la maggior parte dei bug che influisce sull'utente introdotti dalla distribuzione Solo interno, tolleranza elevata per i rischi e i bug Stati Uniti centro-occidentali
1 Aree in cui il team non esegue test approfonditi Clienti che usano un'ampiezza del prodotto Un data center di piccole dimensioni
2 Problemi relativi alla scalabilità Account pubblici, idealmente gratuiti che usano un set diversificato di funzionalità Data center medio o di grandi dimensioni
3 Problemi di scalabilità negli account interni e problemi correlati a livello internazionale Account interni di grandi dimensioni e clienti europei Data center interno e data center europeo
4 Unità di scala rimanenti Tutti gli altri Tutte le destinazioni di distribuzione

Consenti tempo di bake

Il termine tempo di bake si riferisce alla quantità di tempo consentito per l'esecuzione di una distribuzione prima di espandersi all'anello successivo. Alcuni problemi possono richiedere ore o più per iniziare a mostrare i sintomi, quindi il rilascio deve essere in uso per un periodo di tempo appropriato prima che venga considerato pronto.

In generale, un giorno di 24 ore dovrebbe essere sufficiente per la maggior parte degli scenari per esporre bug latenti. Tuttavia, questo periodo deve includere un periodo di picco di utilizzo, che richiede un giorno lavorativo completo, per i servizi di picco durante l'orario di ufficio.

Accelerare gli hotfix

Un evento imprevisto del sito live (LSI) si verifica quando un bug ha un impatto grave nell'ambiente di produzione. Le LSI richiedono la creazione di un hotfix, che è un aggiornamento fuori banda progettato per risolvere un problema ad alta priorità.

Se un bug è Sev 0, il tipo di bug più grave, l'hotfix può essere distribuito direttamente nell'unità di scala interessata il più rapidamente possibile. Anche se è fondamentale che la correzione non faccia peggiorare le cose, i bug di questa gravità sono considerati così dirompenti che devono essere risolti immediatamente.

I bug classificati sev 1 devono essere distribuiti tramite l'anello 0, ma possono essere distribuiti nelle unità di scala interessate non appena approvate.

Gli hotfix per i bug con gravità inferiore devono essere distribuiti tramite tutti gli anelli come previsto.

Punti chiave

Ogni team vuole fornire aggiornamenti rapidamente e al massimo livello di qualità possibile. Con le procedure appropriate, il recapito può essere una parte produttiva e senza dolore del ciclo DevOps.

  • Distribuire spesso.
  • Rimani verde per tutto lo sprint.
  • Usare strumenti di distribuzione coerenti in sviluppo, test e produzione.
  • Usare una piattaforma di recapito continuo che consente l'automazione e l'autorizzazione.
  • Seguire le procedure di distribuzione sicure.

Passaggi successivi

Informazioni su come i flag di funzionalità consentono di controllare l'esposizione di nuove funzionalità agli utenti.