Cosa è una Pipeline ? Una “pipeline di distribuzione” descrive le pratiche e gli strumenti utilizzati per distribuire il software. È una parte essenziale non solo di DevOps, ma anche di Continuous Integration e Continuous Delivery.
L’obiettivo della pipeline di distribuzione è semplice: far arrivare il software dallo sviluppatore agli utenti il più rapidamente, spesso e senza intoppi possibile. Il modo migliore per raggiungere questo obiettivo è l’automazione.
Vediamo le diverse fasi, i metodi e gli strumenti per aiutarvi a costruire o migliorare la vostra pipeline di distribuzione.
Pipeline di creazione e pipeline di distribuzione
La parola “pipeline” viene usata in molti contesti diversi in DevOps, quindi è comprensibile che ci sia confusione sui diversi usi. Ciò è particolarmente vero per le “pipeline di compilazione” e le “pipeline di distribuzione”, che si sovrappongono anche senza la parola “pipeline”.
Una pipeline di compilazione è ciò che avviene tra il commit del codice da parte di uno sviluppatore e la creazione di un artefatto distribuibile. Come parte dell’Integrazione continua, una pipeline di compilazione vi aiuterà a:
- compilare il codice
- testare
- Creare (o attivare la creazione di) un pacchetto distribuibile.
Una pipeline di deploy inizia nello stesso punto, con il commit del codice da parte dello sviluppatore, ma termina molto più tardi con il rilascio nelle mani degli utenti.
Non comprende solo il commit, il testing e la creazione del codice, ma anche il confezionamento e la distribuzione negli ambienti.
Una pipeline di distribuzione è il risultato dell’adozione di Continuous Integration e Continuous Delivery (CI/CD).
Le fasi di una pipeline di distribuzione
Utilizzando un esempio minimo, qualsiasi pipeline di deployment dovrebbe avere almeno 4 fasi chiave:
- Commit
- Build
- Accettazione
- Produzione
Vediamo cosa succede in ogni fase.
Commit
Quando uno sviluppatore finisce di scrivere codice, effettua il commit delle modifiche al ramo principale del team nel repository del codice.
Se si utilizzano correttamente le pratiche DevOps e di Continuous Integration, questo dovrebbe avvenire più volte nel corso della giornata. Il motivo per cui si esegue il commit così spesso è che lotti più piccoli riducono il rischio che le modifiche rompano il software.
Il commit dovrebbe anche attivare i processi nella fase di compilazione.
Build
Quando uno sviluppatore esegue un commit di codice, la pipeline deve consentire di compilare rapidamente il codice:
- Compilare il codice
- Testare il codice alla ricerca di errori
- Fornire un feedback quasi istantaneo allo sviluppatore in caso di problemi
- Confezionare il codice per il deploy
Si dovrebbe usare lo stesso artefatto distribuibile per ogni distribuzione di questa release, indipendentemente dal target o dall’ambiente.
Accettazione
La fase di accettazione consiste nello distribuire la modifica negli ambienti di ‘sviluppo’ o di ‘test’.
Qui i test automatizzati possono verificare che il codice non presenti problemi che potrebbero avere un impatto sugli utenti in diversi scenari. Ciò può includere test sulle prestazioni o sulla sicurezza.
Una volta certi che l’aggiornamento è valido, è possibile promuovere il rilascio attraverso la struttura dell’ambiente per il test manuale.
Produzione
La fase di produzione arriva quando è il momento di distribuire le modifiche all’ambiente live (noto anche come “produzione”), in modo che gli utenti possano mettere le mani sulle nuove funzionalità o correzioni.
Da qui è possibile monitorare l’ambiente di produzione per verificare che non si verifichino:
- Problemi o bug inaspettati
- Problemi riscontrati dagli utenti
- Modi per migliorare le aree della pipeline attraverso l’automazione o le modifiche ai processi e alle approvazioni.
I componenti dell’automazione della pipeline di distribuzione
Naturalmente, per soddisfare le best practice DevOps, è fondamentale automatizzare quasi tutto nella pipeline di deployment.
Vediamo alcuni strumenti che vi aiuteranno a raggiungere questo obiettivo.
Server di compilazione o piattaforma CI
Un server di compilazione è il più grande risparmio di tempo che si possa aggiungere alla pipeline di distribuzione.
Ogni volta che uno sviluppatore effettua un commit di codice, un server di compilazione completerà automaticamente tutte le fasi di compilazione, tra cui:
- Compilazione del codice
- Test in base alle esigenze del software
- Superamento o fallimento del codice (e risposta allo sviluppatore in caso di fallimento).
- fusione del codice se supera i test
- Confezionamento del codice in un artefatto distribuibile (o consegna a un sistema di packaging, a seconda degli strumenti del team).
Tradizionalmente, l’unica opzione per i server di compilazione erano le opzioni self-hosted, come l’open-source e ancora il popolare Jenkins. Jenkins rimane un’opzione popolare grazie alle sue opzioni di personalizzazione e alla sua scalabilità.
Tuttavia, con le nuove tecnologie arrivano anche nuove scelte. La popolarità crescente è quella che chiamiamo “integrazione continua come servizio“. Ciò significa che le funzioni di build presenti nelle piattaforme di build basate sul cloud eliminano la necessità di ospitare la propria infrastruttura per le build.
In effetti, anche la maggior parte dei servizi di repository Git ora offre funzioni di build. GitHub, per esempio, offre GitHub Actions, che può eseguire attività di build direttamente dal vostro repo.
La scelta del server o del servizio di build deve riflettere le esigenze di distribuzione del software. Se l’organizzazione impone l’archiviazione in cloud basata sulla posizione o insiste su strumenti on-premise, un server di compilazione self-hosted è l’unica opzione possibile.
Packaging
Gli strumenti di packaging possono trasformare automaticamente il codice in un artefatto distribuibile.
Lo strumento di impacchettamento da usare può dipendere dal linguaggio in cui si codifica e dal target in cui si distribuisce. Se si distribuisce su container, per esempio, si vuole uno strumento che crei immagini di container, di solito nel formato OCI di Docker.
Data l’estensibilità della maggior parte degli strumenti di compilazione, molti sono in grado di pacchettizzare il codice (o almeno di attivare una compilazione con un servizio di pacchettizzazione dedicato). Tuttavia, è necessario pensare anche alla memorizzazione delle immagini.
La maggior parte delle opzioni di packaging, come Docker Hub, offre registri per catalogare e archiviare le immagini. In questo modo, il team e gli strumenti di distribuzione possono trovare facilmente ciò di cui hanno bisogno.
Deployments
Ci sono alcune cose da considerare quando si sceglie uno strumento di automazione del deployment.
In primo luogo, ciò di cui si ha bisogno può dipendere dall’oggetto del deployment e dalla sua complessità. Se si distribuisce un’applicazione semplice in un singolo contenitore, la maggior parte delle soluzioni di build server può gestire il deployment.
Il deploy attraverso un server di build potrebbe non essere adatto se si dispone di un insieme complesso di target o ambienti di utilizzo.
In secondo luogo, la gestione delle distribuzioni raramente significa distribuire su un unico target di hosting. Al contrario, si dovrebbe distribuire su molti target all’interno della struttura dell’ambiente.
Anche senza DevOps, la maggior parte degli sviluppatori conosce la pratica di promuovere i rilasci attraverso almeno 3 ambienti (anche se molti team ne usano molti di più). Una struttura minima di ambienti potrebbe essere la seguente:
- Development (o “dev”): Dove gli sviluppatori possono distribuire e testare rapidamente i loro aggiornamenti.
- Test (o “QA”): Per i team QA, che possono testare il software come lo sperimenterebbero gli utenti.
- Production (o “prod”): L’ambiente live in cui le persone utilizzano o accedono al vostro software.
Ogni ambiente può avere innumerevoli target di distribuzione diversi al suo interno. Ad esempio, potreste avere:
- Server in ogni regione in cui operate, per contribuire alle prestazioni a livello mondiale.
- configurazioni di bilanciamento del carico o ad alta disponibilità
- Un mix di cloud e server fisici per tenere conto dei diversi modi in cui le persone utilizzano o ottengono il vostro software.
- I server di build non vedono gli obiettivi di distribuzione nel quadro generale dei vostri ambienti. Questo può rendere difficile capire quale release è stata distribuita e dove. Uno strumento di distribuzione dedicato risolve questo problema.
Riepilogo
Abbiamo esplorato:
- La definizione e gli obiettivi di una pipeline di distribuzione
- Le diverse fasi di una pipeline di distribuzione e la loro funzione
- I modi per automatizzare la pipeline di distribuzione e perché sono una buona idea.
Ora che sapete cos’è una pipeline di distribuzione, perché non crearne una? Octopus ha recentemente sviluppato Octopus Workflow Builder, che può creare una pipeline di distribuzione completa in pochi minuti. Esso:
- Crea un repository GitHub con un’applicazione di microservizio di esempio.
- Imposta i flussi di lavoro delle azioni GitHub per costruire l’applicazione campione e inviare gli artefatti a un’istanza Octopus.
- Popola un’istanza Octopus con:
- Ambienti
- Cicli di vita
- Conti
- Feed
- Progetti di distribuzione
- Distribuisce su piattaforme cloud come EKS, ECS e Lambda utilizzando Octopus.
Innovaformazione, scuola informatica specialistica promuove la cultura DevOps e le metodologie di CI/CD. L’offerta formativa per aziende comprende una serie di corsi che trovate sul nostro sito QUI.
INFO: info@innovaformazione.net – tel. 3471012275 (Dario Carrassi)