Parliamo dunque di Pipelines, che in inglese vuol dire “tubatura” oppure “oleodotto”. Questo è un nome convenzionale con cui si indica un processo, costituito da più passi, per partire dal codice e arrivare a un punto desiderato. Alcuni usano un nome diverso, per esempio Github lo chiama “Actions”, ma il concetto è lo stesso
Altri lo chiamano “Continuos Integration / Continuous Delivery”, partendo dai suoi due usi principali. Purtroppo questa sigla è un po’ ostica sia da capire che da pronunciare, per cui noi useremo il nome “Pipeline”, che è breve e facilmente memorizzabile e pronunciabile
In realtà poi gli scopi principali si possono divider in 3, non in 2: c’è anche il Continuos Deploy. Ma andiamo per ordine
Il primo passo è il trigger, cioè cioò che fa scattare la pipeline (una singola istanza di una pipeline è anche detta “build”). Questo trigger, anche se può sembrare banale specificarlo, è un push su un repository. In realtà si possono configurare trigger più elaborati, per esempio basati sul ramo in cui è stato eseguito il push o sulla presenza di determinate parole all’interno dei messaggi di commit. Per esempio un tipico e convenzionale messaggio di commit è “[skip ci]” (oppure “[ci skip]”), che nello specifico dice alla pipeline non deve partire. È molto utile quando facciamo piccoli commit estetici e vogliamo evitare di sovraccaricare il sistema
Al trigger seguireanno una serie di azioni, che vengono eseguite in base alla configurazione fornita alla pipeline (torneremo più avanti sulla questione della configurazione con esempi concreti)
la prima azione è tipicamente l’esecuzione dei test. Sappiamo che lo sviluppatore coscienzioso avrà già eseguito i test in locale prima ancora di aver pushato il codice, ma sappiamo anche che un test su un secondo ambiente sono sempre desiderabili.
Inoltre nella CI possiamo includere ulteriori eventuali azioni, come per esempio la copertura, un’analisi statica del codice o la raccolta di altre metriche
arrivamo poi al Continuos delivery o deployment. Qui entriamo nel campo della discrezionalità: fino alla CI siamo più o meno su un terreno “obbligato”, sul minimo sindacale. Se i test sono rossi, la build fallisce e la pipeline si blocca. Ma se sono verdi, vogliamo poter fare una serie di azioni, che potrebbero essere: deployare su stage, in modo che un QA faccia le sue verifiche e quindi possa approvare un deploy in produzione (questa è la C. Delivery). Qualcuno si spinge più in là e fa direttamente il deploy in produzione (questo si chiama C. Deploy). Chiaramente le opzioni dipendono largamente al tipo di processo che si vuole adottare
l’accenno fatto alla C. Delivery ci fa capire che, oltre alle normali azioni sequenziali, la pipeline può essere composta da azioni condizionali. Proprio come nella metafora del tubo che trasporta un materiale, ci possono essere delle biforcazioni e dei rubinetti da azionare manualmente
cerchiamo ora di sporcarci un po’ le mani e di vedere qualcosa di pratico, visto che finora abbiamo fatto tutta teoria e non voglio risultare troppo noioso
il punto di partenza è il vostro Source Code Management
sappiamo che la “sacra trimurti” degli SCM è costituita da Github, Bitbucket e GitLab. Tutti e tre questi sistemi offrono una loro sintassi per le pipeline. Il sistema di Github è ancora in beta e ne va richiesta l’attivazione. Per questo motivo non lo esamineremo qui (non perché non sia valido, molto probabilmente lo è, ma semplicemente perché non ho avuto ancora l’opportunità di provarlo e perché si trova ancora poco aiuto online)
ma c’è anche un’ulteriore possibilità: quella di usare un servizio esterno, che si interfaccia tramite API al vostro SCM e che si occupa della pipeline. Ce ne sono parecchi a disposizione, ne vedremo uno in particolare
esempio per bitbucket
esempio per gitlab
esempio per circleCI
esempio per circleCI
esempio per circleCI
esempio per circleCI
esempio per circleCI. Altri strumenti interessanti: binario per far girare gli step in locale, possibiltà di rieseguire una build fallita con accesso SSH
ecco come appare la visualizzazione del workflow nell’interfaccia di circleCI
ecco un esempio di accesso all’immagine di circleCI che ha girato. L’immagine sarà disponibile per un tempo limitato
Abbiamo finito! Spero di vedere, da domani, tutte le vostre pipeline!