Pipeline DevOps

1. Continuous integration/continuous delivery/deployment (CI/CD)

Continuous integration indica la pratica di eseguire commit frequenti in un repository di codice sorgente comune. Integra continuamente le modifiche al codice nella base di codice esistente in modo che eventuali conflitti tra le modifiche al codice di diversi sviluppatori vengano identificate in modo rapido e siano relativamente facili da risolvere. Questa pratica ha un'importanza fondamentale per aumentare l'efficienza della distribuzione.

Riteniamo che lo sviluppo basato su trunk sia un requisito di continuous integration. Se non si eseguono commit frequenti su un branch comune in un repository di codice sorgente condiviso, significa che non si sta effettuando la continuous integration. Se i processi di build e test sono automatizzati, ma gli sviluppatori lavorano su branch di funzionalità isolati e di vecchia data che sono raramente integrati in un branch condiviso, significa che non si sta effettuando la continuous integration.

Continuous delivery garantisce che il branch "principale" o "trunk" del codice sorgente di un'applicazione sia sempre in uno stato rilasciabile. In altre parole, se il capo si presentasse alla tua scrivania alle 16:30 di venerdì e dicesse: "Abbiamo bisogno subito dell'ultima versione rilasciata", quella versione potrebbe essere distribuita premendo un pulsante e senza timore di errori.

Ciò significa disporre di un ambiente di pre-produzione il più vicino possibile o identico all'ambiente di produzione e garantire l'esecuzione di test automatizzati, in modo che ogni variabile in grado di causare un errore sia identificata prima che il codice venga unito al branch o trunk principale.

Continuous deployment implica un livello di test e operazioni continui così solido da consentire la convalida e la distribuzione di nuove versioni del software in un ambiente di produzione senza alcun intervento umano.

Questo avviene raramente e nella maggior parte dei casi non è necessario. In genere, questo livello di automazione è richiesto, o addirittura desiderato, solo dalle aziende unicorno che hanno centinaia o migliaia di sviluppatori e che ogni giorno effettuano numerosi rilasci.

Per semplificare la differenza tra continuous delivery e continuous deployment, la prima può essere paragonata alla consegna di una scatola da parte di un corriere FedEx, mentre la seconda all'apertura e all'uso del contenuto della scatola. Se è necessario apportare una modifica al prodotto tra il momento in cui ricevi la scatola e quello in cui la apri, il produttore è nei guai!

2. Feedback continuo

La principale criticità del vecchio metodo waterfall usato per lo sviluppo software e, di conseguenza, il motivo per cui sono state progettate metodologie Agile, è stata la mancanza di feedback tempestivi. Quando il passaggio dall'idea all'implementazione di nuove funzioni richiedeva mesi o persino anni, era quasi certo che il risultato finale sarebbe stato diverso da quello che il cliente si aspettava o desiderava. L'approccio Agile è riuscito a garantire che gli sviluppatori ricevessero un feedback più rapido dagli stakeholder. Ora con DevOps, gli sviluppatori ricevono feedback continui non solo dagli stakeholder, ma anche da test e monitoraggio sistematici del loro codice nella pipeline.

Il test continuo è una componente fondamentale di ogni pipeline DevOps nonché uno dei principali fattori abilitanti del feedback continuo. In un processo DevOps, le modifiche passano continuamente dallo sviluppo al test fino alla distribuzione, il che determina non solo a rilasci più veloci, ma un prodotto di qualità più elevata. Ciò significa disporre di test automatizzati in tutta la pipeline, inclusi test unitari eseguiti su ogni modifica di build, smoke test, test funzionali e test end-to-end.

Il monitoraggio continuo è un'altra componente importante del feedback continuo. L'approccio DevOps comporta l'uso del monitoraggio continuo negli ambienti di staging, test e persino di sviluppo. Talvolta è utile monitorare gli ambienti di pre-produzione per rilevare comportamenti anomali, ma in genere si tratta di un approccio usato per valutare continuamente lo stato e le prestazioni delle applicazioni in produzione.

Esistono numerosi strumenti e servizi che forniscono questa funzionalità e ciò può comportare qualsiasi aspetto, dal monitoraggio dell'infrastruttura on-premise o cloud come le risorse del server, la rete e così via, al monitoraggio delle prestazioni dell'applicazione o delle sue interfacce API.

3. Operazioni continue

Operazioni continue è un termine relativamente nuovo e meno diffuso la cui definizione è variabile. È possibile interpretarlo è come "tempo di attività continuo". Ad esempio nel caso di una strategia di distribuzione blu/verde in cui sono presenti due ambienti di produzione separati, quello "blu",che è accessibile pubblicamente, e quello "verde" che non è accessibile pubblicamente. In questa situazione, il nuovo codice verrebbe distribuito nell'ambiente verde e, una volta confermato il corretto funzionamento, si attiverebbe un interruttore (di solito su un sistema di bilanciamento del carico) e il traffico verrebbe reindirizzato dal sistema "blu" al sistema "verde". Il risultato è l'assenza di tempo di inattività per gli utenti finali.

Le operazioni continue possono anche essere paragonate agli avvisi continui, un concetto che prevede la presenza di personale tecnico su reperibile chiamata al quale vengono inviate notifiche in caso di anomalie delle prestazioni dell'applicazione o dell'infrastruttura. Nella maggior parte dei casi, gli avvisi continui vanno di pari passo con il monitoraggio continuo.