Usare il recapito continuo per un rilascio più rapido, con costi e rischi minori

Completato

Il recapito continuo è una delle otto funzionalità della tassonomia di DevOps.

Perché il recapito continuo è necessario

In 2012, un errore di distribuzione di un software costò 460 milioni di dollari USA al gruppo Knight Capital, il più grande trader di azioni degli Stati Uniti di allora.

Le perdite iniziarono al momento dell'apertura del mercato azionario. Non vi erano bug nel codice; il problema fu causato da un errore che si era verificato durante una distribuzione manuale in uno solo degli otto server di produzione.

Nel tentativo di risolvere il problema, tutti e otto i server finirono per presentare errori di configurazione, il che comportò un'ulteriore perdita di denaro. Poiché tutta la distribuzione era manuale, non fu possibile eseguire automaticamente il rollback delle modifiche.

Dopo aver tentato di risolvere il problema per 45 minuti, l'intero sistema dovette essere arrestato. In quel momento, perdettero 460 milioni di dollari USA.

Questa è una storia vera. Quale sarebbe l'impatto sulla propria organizzazione? L'organizzazione usa la distribuzione manuale?

Probabilmente, la domanda più importante da porsi per tentare di comprendere le prestazioni di recapito di un'organizzazione è:

Importante

Quanto è grande il fardello della distribuzione alla produzione?

Il timore e l'ansia degli ingegneri e del personale tecnico al momento del push del codice nell'ambiente di produzione possono dire molto delle prestazioni di recapito del software di un team.

Che cos'è il recapito continuo?

Importante

Il recapito continuo è un approccio di ingegneria del software in cui i team producono software in cicli brevi e si assicurano che il software sia:

  • Rilasciato in modo affidabile in qualsiasi momento
  • Rilasciato manualmente

Lo scopo del recapito continuo è:

  • Creare, testare e rilasciare software con maggiore velocità e frequenza
  • Ridurre il costo, il tempo e il rischio di recapito delle modifiche grazie al maggiore utilizzo di aggiornamenti incrementali delle applicazioni nell'ambiente di produzione

Il recapito continuo si verifica nei casi seguenti:

  • Il software è distribuibile lungo l'intero ciclo di vita
  • L'integrazione continua e l'automazione completa sono disponibili in tutte le parti possibili del processo di recapito, in genere attraverso una pipeline di distribuzione
  • È possibile eseguire distribuzioni immediate su richiesta con un solo clic di qualsiasi versione del software in qualsiasi ambiente

Diagram shows the difference between continuous delivery and continuous deployment. The stages are the same in both cases: code done - unit tests - integrate - acceptance test - deploy to production. For continuous delivery, deployment to production happens manually. For continuous deployment, it's automatic.

Le distribuzioni manuali di grandi dimensioni creano un elevato livello di rischio perché aumentano drasticamente la complessità del software rilasciato e introducono la probabilità di errori umani e rendono più difficile l'individuazione e la risoluzione degli errori di distribuzione. La frequenza della distribuzione è bassa, il lead time delle modifiche è elevato, il tempo medio per il recupero è lungo e si registra una frequenza elevata di errori di modifica.

Un team operativo designato esegue la distribuzione manuale al di fuori dell'orario di ufficio. Sono necessari un documento dei passaggi manuali e il tempo per testare manualmente i passaggi documentati. Le distribuzioni di grandi dimensioni richiedono tempi di esecuzione più lunghi, è difficile eseguire il rollback in caso di errore e riguardano un ambito di test più ampio dopo la distribuzione. Il numero delle modifiche in ogni distribuzione è maggiore e l'implementazione del feedback richiede più tempo.

Grazie all'automazione del processo e alla possibilità di eseguire il rilascio alla produzione in qualsiasi momento, i vantaggi del recapito continuo sono significativi e numerosi:

Diagram shows the circle of Continuous Delivery. The cycle goes from planning and tracking to development, building and testing, deployment, operation, monitoring and learning, and back to planning.

Secondo il report State of DevOps Report del 2019, le organizzazioni DevOps con prestazioni elevate rispetto alle organizzazioni con prestazioni basse ottengono:

  • Distribuzioni oltre 200 volte più frequenti
  • Lead time delle modifiche oltre 100 volte più rapido
  • Tempo medio per il ripristino oltre 2600 volte inferiore
  • Percentuale di errori di modifica sette volte inferiore

Inoltre, secondo uno studio globale di CA Technology, le organizzazioni realizzano un miglioramento fino al 20% del tempo di immissione sul mercato e dei ricavi.

Diagram shows the advantages of high-performing DevOps organizations using Continuous Delivery over low performers.

Nota

Il recapito continuo talvolta viene confuso con la distribuzione continua. La distribuzione continua indica che tutte le modifiche passano attraverso la pipeline e arrivano automaticamente alla produzione, il che significa molte distribuzioni alla produzione al giorno. Il recapito continuo indica semplicemente che è possibile eseguire distribuzioni frequenti, ma si può anche scegliere di non eseguirle, in genere nel caso di aziende che preferiscono una velocità di distribuzione più lenta. Per eseguire la distribuzione continua è necessario eseguire il recapito continuo.

L'integrazione continua è un prerequisito del recapito continuo. Le procedure esistenti consentono di creare e di distribuire (in modo affidabile) l'applicazione in qualsiasi momento e con qualità elevata dal controllo del codice sorgente.

Diagram shows the relationship between Continuous Integration, Continuous Delivery and Continuous Integration