Modello di distribuzione di recapito continuo

Si sono appresi molti svantaggi della "distribuzione epica" come modello di distribuzione software, ma sapere cosa non funziona bene è solo metà della battaglia. In questa unità vengono fornite informazioni sull'alternativa al metodo monolitico e su come può aumentare l'obiettivo di migliorare l'affidabilità.

Vale anche la pena distinguere due termini correlati che a volte vengono usati in modo intercambiabile:

• Recapito continuo: ogni modifica che supera i test automatizzati è pronta per essere distribuita nell'ambiente di produzione, ma la versione effettiva all'ambiente di produzione viene controllata da un'approvazione manuale.
• Distribuzione continua: ogni modifica che supera i test automatizzati viene rilasciata automaticamente all'ambiente di produzione, senza gate manuale.

Entrambi dipendono dalle stesse basi (integrazione frequente, test automatizzati, pipeline ripetibili). Questo modulo è incentrato su queste basi condivise.

Che cos'è la consegna continua?

Il recapito continuo è un metodo in base al quale ogni modifica alla codebase viene mantenuta rilasciabile in modo più veloce, meno stressante, meno rischioso e riproducibile. Invece di rendere ogni distribuzione software o aggiornamento come un evento epico, la consegna continua lo trasforma in un'esperienza rapida, routinaria e prevedibile che si verifica su richiesta.

• Frequenza di distribuzione: con un modello di recapito continuo, le distribuzioni avvengono frequentemente, La frequenza può essere mensile, settimanale, giornaliera o persino oraria. La chiave è che si implementano più spesso modifiche più mirate e di dimensioni ridotte.

• Attivato dal commit del codice: invece di attendere una finestra di rilascio pianificata in anticipo, la pipeline di recapito inizia quando viene eseguito il commit del codice. Questo codice può essere un software, un'infrastruttura o anche elementi come configurazioni software. Ogni modifica viene quindi compilata, testata e mantenuta pronta per il rilascio. A seconda dei controlli dell'organizzazione, la promozione alla produzione può comunque verificarsi in un secondo momento, dopo un'approvazione.

• Test automatizzati: è possibile usare test automatizzati integrati non solo per testare il codice, ma anche per fornire un rapido feedback sui risultati. È questo rapido feedback che consente di eseguire rapidamente l'iterazione e il ripristino dai test non superati.

  Una volta testato il codice, è possibile testare la distribuzione end-to-end in una serie di ambienti di gestione temporanea, come test, QA e così via. L'implementazione delle distribuzioni attraverso questi ambienti diventa una parte integrante dell'esperienza di distribuzione.

• Record cronologici: oltre ad avere un record cronologico delle attività di distribuzione, è necessario anche essere in grado di riconciliare l'ambiente di produzione in un determinato momento. Si vuole comprendere quale distribuzione ha creato l'ambiente di produzione corrente. Con queste informazioni è possibile ricondurre elementi come configurazioni, risultati dei test e il codice stesso alla singola richiesta pull che ha attivato la distribuzione.

Obiettivi di distribuzione

Ora che hai compreso il funzionamento della consegna continua, considera gli obiettivi che la consegna continua e altre pratiche DevOps ti aiutano a raggiungere nella distribuzione di soluzioni software.

Obiettivo 1: ridurre lo stress legato alla distribuzione dei servizi aumentandone l'affidabilità

La riduzione dello stress delle distribuzioni di software e infrastruttura migliora l'esperienza quotidiana dei tecnici che li gestiscono. L'aumento dell'affidabilità comporta anche vantaggi per gli utenti finali, che vedono meno interruzioni e guasti.

Obiettivo 2: ridurre il tempo che intercorre tra quando si sa che è richiesta una modifica e la sua distribuzione nell'ambiente di produzione

Si supponga, ad esempio, di aver identificato un difetto del codice che influisce sulle entrate e di sapere esattamente come risolverlo. Con le procedure DevOps mature, il percorso dal commit alla produzione è breve e prevedibile. La modifica viene compilata, testata automaticamente negli ambienti pertinenti e preparata per il rilascio entro pochi minuti. Una volta data l'approvazione richiesta, può essere promossa alla produzione invece di essere mantenuta per una finestra di rilascio futura.

Obiettivo 3: Ridurre il tempo tra avere un'idea e distribuire software utilizzabile

Questo obiettivo è simile a quello precedente, ma si concentra sull'innovazione anziché sulle correzioni. Quanto tempo ci vuole per agire su una nuova idea? Con questo modello di distribuzione, è possibile integrare un nuovo concetto in un sistema di produzione con la certezza che l'aggiunta non interrompe o ostacola il sistema corrente. Tale attendibilità consente di offrire rapidamente nuove funzionalità.

Risultati della distribuzione

Gli obiettivi illustrati in questa unità non sono solo aspirazioni teoriche, sono misurabili. Dal 2014, il team devOps Research and Assessment (DORA) ha pubblicato una ricerca annuale su DevOps sulle prestazioni di distribuzione del software. Negli ultimi anni, questo lavoro è stato pubblicato come il Accelerate State of DevOps Report. Il modello DORA corrente tiene traccia di cinque metriche di recapito:

• Frequenza di distribuzione
• Modifica del tempo di consegna
• Tasso di errore delle modifiche
• Tempo di ripristino dopo un fallimento della distribuzione
• Tasso di modifica della distribuzione

L'anno dopo anno, la ricerca mostra che i team con prestazioni più elevate offrono modifiche più frequentemente, passano dal commit alla produzione più velocemente, recuperano dalle distribuzioni non riuscite e dedicano meno tempo a risolvere i problemi correlati alla distribuzione. Per le definizioni più recenti di ricerca e metrica, vedere le metriche di distribuzione software di DORA.

Questi risultati convalidano l'idea che le procedure di distribuzione siano importanti.