Modello di distribuzione di recapito continuo
Sono stati illustrati i numerosi svantaggi della "distribuzione epica" come modello di distribuzione del software, ma essere consapevoli di ciò che non funziona bene vuol dire solo essere a metà della battaglia. In questa unità verrà presentata l'alternativa a questo metodo monolitico, con particolare attenzione al modo in cui può contribuire all'obiettivo di maggiore affidabilità.
Che cos'è il recapito continuo?
Il recapito continuo è un metodo con cui è possibile rendere disponibili per l'uso modifiche al software in modo più rapido, meno stressante, meno rischioso e più riproducibile. Anziché rendere ogni distribuzione software o aggiornamento un evento epico, il recapito continuo lo trasforma in un'esperienza di routine rapida e prevedibile che si verifica su richiesta.
Frequenza di distribuzione: con un modello di recapito continuo, le distribuzioni avvengono frequentemente, vale a dire mensilmente, settimanalmente, quotidianamente o addirittura ogni ora. La chiave è che si distribuiscono più spesso modifiche più mirate e di dimensioni ridotte.
Avvio dal commit del codice: invece di essere pianificate con molto anticipo, le distribuzioni avvengono quando si esegue il commit del codice. Questo codice può essere un software, un'infrastruttura o anche elementi come configurazioni software.
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 si è appreso come funziona il recapito continuo, prendere in considerazione gli obiettivi che è possibile ottenere usando procedure DevOps come queste per la distribuzione di soluzioni software.
Obiettivo 1: ridurre lo stress legato alla distribuzione dei servizi aumentandone l'affidabilità
È un vantaggio per tutti: non solo si aumenta la soddisfazione per i processi riducendo lo stress legato alle distribuzioni di software e infrastruttura, ma si aumenta anche la soddisfazione per i processi e degli utenti finali rendendo i sistemi più affidabili. Considerato l'impatto positivo sull'esperienza del cliente, tecnicamente è una situazione che sta bene a tutti.
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 incide sul fatturato. Si sa esattamente quale sia il problema e come codificare la correzione. Quanto tempo è necessario per implementare tale codice nell'ambiente di produzione? Di quante stringhe è necessario eseguire il pull? Come si esegue il test? Con le procedure DevOps, è possibile eseguire il commit del codice, uscire a pranzo e ricevere una notifica che segnala che il problema è stato risolto prima di tornare in ufficio.
Obiettivo 3: ridurre il tempo che intercorre tra la nascita di un'idea e la distribuzione di software utilizzabile
È molto simile all'obiettivo precedente, ma invece di implementare le modifiche, si parla di innovazione pura. Quanto tempo è necessario per agire sull'innovazione? Con questo modello di distribuzione, è possibile integrare un nuovo concetto in un sistema di produzione e avere la certezza che l'innovazione aggiunta non interromperà né ostacolerà in alcun modo il sistema corrente. Con questa sicurezza, è possibile distribuire rapidamente la nuova funzionalità.
Risultati della distribuzione
Gli obiettivi illustrati in questa unità non sono solo aspirazioni teoriche, sono raggiungibili. Di seguito sono riportate alcune statistiche del 2019 Accelerate State of DevOps Report a cura di DevOps Research and Assessment (DORA) e Google Cloud DevOps & SRE. È emerso che le aziende DevOps "a prestazioni elevate":
- Hanno un numero di distribuzioni 208 volte superiore.
- Sono 106 volte più veloci dal commit alla distribuzione.
- Hanno una percentuale di errori di modifica 7 volte inferiore.
- Hanno un tempo di recupero dagli incidenti 2604 volte più veloce.
Tutto ciò comporta un aumento dei ricavi e tempi di commercializzazione più rapidi.
Questi numeri convalidano il concetto dell'importanza delle procedure di distribuzione.