Formazione scritta DevOps

Perché attivare il feedback per deployment in produzione più sicuri?

Nei mercati competitivi come il tuo, tenere i reparti di assicurazione della qualità e delle attività operative separati dal team di sviluppo non è una soluzione accettabile se vuoi servire rapidamente i clienti e soddisfare le loro richieste. Anche se la maggior parte degli sviluppatori si lamenta della burocrazia, quando può lavorare con specialisti della qualità e delle attività operative nel proprio team continua a temere di effettuare deployment in produzione senza supervisione. Vediamo quindi quali tecniche e misure adottare per rendere più sicuri i deployment in produzione.

Come favorire un flusso DevOps continuo

Per ottenere un flusso continuo e regolare, le organizzazioni DevOps di maggior successo distribuiscono frequentemente piccoli lotti di modifiche nei sistemi di produzione. Così ogni persona nei team DevOps può valutare e comprendere le modifiche e correggerle quando necessario.

Costruire una pipeline di deployment automatizzata da sola non basta. Integra la telemetria operativa nella pipeline per ricevere feedback rapido sugli esiti delle modifiche negli ambienti di produzione e preproduzione. Inoltre, crea una cultura comune nell'organizzazione in cui tutti nel team DevOps sono responsabili del buon funzionamento e della continuità dell'intero flusso di valore e della pipeline di deployment.

Affidati alla telemetria per deployment più sicuri

Non contrassegnare mai una modifica e il relativo deployment come completati finché non dimostri che funzionano come previsto dal progetto e dal codice. Dopo il deployment, monitora da vicino le metriche dei moduli modificati, le eventuali nuove metriche e quelle degli altri componenti del sistema su cui la modifica potrebbe incidere.

Anche eseguendo test automatizzati in preproduzione e monitorando il sistema in prova con la telemetria, continueranno a verificarsi problemi in produzione. Non puoi prevenirli tutti, ma puoi prepararti bene a correggerli. Se una modifica blocca la pipeline, riunisci tutti gli specialisti necessari per risolvere il problema e ripristinare la pipeline. Ecco tre metodi usati di frequente:

1. Disattivare la funzionalità: È il modo più semplice per correggere un problema. Non richiede un deployment urgente del codice. Basta disattivare la funzionalità con il relativo feature toggle. Non devi correggere in fretta gli elementi errati del deployment, così il team può prendersi il tempo per individuare correttamente la causa alla radice e migliorare le proprie tecniche, riducendo la probabilità che il problema si ripeta.
2. Correggere il problema con una modifica successiva (fix forward): Distribuisci nuovo codice per risolvere il problema. Nelle organizzazioni IT tradizionali il fix forward è rischioso per i problemi in produzione. Nelle organizzazioni DevOps può funzionare bene, in modo efficiente e sicuro, se sono disponibili test e deployment automatizzati e telemetria di produzione completa.
3. Eseguire il rollback della modifica: Rimuovi il codice errato e, si spera, il problema scompare.

Fai in modo che gli sviluppatori ricevano riscontri dall'esperienza operativa reale

Ruota le persone del team DevOps nei compiti dei team operativi perché gestiscano gli incidenti. Così, tutti nel flusso di valore capiscono difficoltà e responsabilità delle unità operative a valle. Assegna compiti operativi non pianificati a sviluppatori, tester, architetti, progettisti, responsabili e dirigenti, in modo che ricevano chiamate di allerta alle 3 del mattino. Ognuno potrà così farsi un'idea concreta delle conseguenze delle decisioni che prende ogni giorno.

Una rotazione simile aiuta gli specialisti delle attività operative a non sentirsi isolati. Tutti nel team DevOps contribuiscono a bilanciare correzione degli incidenti in produzione, riduzione del debito tecnico e sviluppo di nuove funzionalità. È chiaro che, svegliando architetti e sviluppatori alle 3 del mattino, gli incidenti si risolveranno più rapidamente che mai.

Quando osservano i clienti usare il software, gli sviluppatori fanno molte scoperte su ciò che dovrebbero migliorare subito. Lo stesso accade quando architetti, progettisti, sviluppatori e tester osservano internamente le unità a valle del ciclo di ingegneria del software. Capendo l'impatto del proprio lavoro sulle unità a valle, acquisiscono una prospettiva nuova per migliorare la qualità e affinare i risultati, così da aiutare quelle unità a lavorare meglio. Tutti nel team DevOps iniziano a includere nei backlog i requisiti operativi non funzionali come parte del lavoro quotidiano. Questo è possibile solo attivando cicli di feedback rapidi e continui nell'organizzazione.

Affida agli sviluppatori la gestione del proprio sistema

Trasferire ai team di sviluppo ciò che si impara sui sistemi reali di produzione è molto difficile. Alcune importanti organizzazioni DevOps, tra cui Google, affidano quindi ai team di sviluppo la gestione operativa del software durante e dopo il lancio iniziale. In questa fase gli ingegneri operativi fanno da consulenti. Una volta dimostrato che il prodotto è abbastanza stabile in produzione per circa 6 mesi, viene passato ai team operativi. Il passaggio può avvenire solo se il prodotto supera una serie di verifiche, ad esempio su difetti passati e in corso, copertura della telemetria, incidenti fuori orario, architettura debolmente accoppiata e sicurezza di modifiche e deployment.

Se, una volta passato al team operativo, il prodotto rivela problemi rilevanti di progettazione o codifica prima sfuggiti, può essere riconsegnato agli sviluppatori. In questa fase gli sviluppatori stabilizzano il software e gli ingegneri operativi fanno da consulenti.

CONCLUSIONE

In questo capitolo abbiamo illustrato varie tecniche per rendere il flusso delle pipeline di deployment più sicuro ed efficace nell'organizzazione DevOps.

Queste tecniche mostrano esempi di rispetto e collaborazione reciproci tra sviluppatori e ingegneri operativi nei team DevOps.