Best practice per l'integrazione continua

Come regola generale, è molto più facile risolvere problemi piccoli piuttosto che grandi. Uno dei maggiori vantaggi dell'integrazione continua è l'integrazione del codice in un repository condiviso che permette di applicare modifiche apportate simultaneamente. Se un team di sviluppo esegue il commit delle modifiche al codice presto e spesso, è più facile individuare i bug perché la quantità di codice da revisionare sarà minore.

Eseguendo i test in piccoli lotti, la qualità del codice viene migliorata e i team possono iterare in modo più efficace.

I sistemi di integrazione continua rendono la documentazione ampiamente disponibile e questa può risultare molto utile anche dopo aver implementato la CI nel flusso di lavoro. In GitLab, disponiamo di una documentazione CI/CD completa, che viene aggiornata frequentemente per riflettere i processi più recenti.

Può essere utile fare riferimento alla documentazione nei file README o in altri formati accessibili. Invita i membri del team a leggere prima la documentazione, aggiungi link ai segnalibri, crea documenti di domande frequenti e incorpora queste risorse nel processo di onboarding dei nuovi membri del team.

Le pipeline CI contengono job e stage: i job sono le attività che si svolgono all'interno di uno stage specifico e, una volta passati tutti i job, il codice si sposta alla fase successiva. Per ottenere il massimo dalle pipeline CI, ottimizza gli stage in modo che sia più semplice individuare e correggere gli errori.

Gli stage sono un modo semplice per organizzare job simili, ma potrebbero esserci alcuni job nella pipeline eseguibili in maniera sicura in uno stage precedente, senza che ciò influisca negativamente sul progetto nel caso in cui dovessero fallire. Prendi in considerazione l'esecuzione di questi job in uno stage precedente per accelerare le pipeline CI.

Non c'è niente che rallenti una pipeline più della sua complessità. Cerca di mantenere le build veloci: il miglior modo per farlo è renderle il più semplici possibile.

Ogni minuto tolto in fase di creazione della build è un minuto risparmiato ad ogni commit degli sviluppatori. Poiché la CI richiede commit frequenti, questo tempo risparmiato si somma. Secondo Martin Fowler, una build può essere creata in dieci minuti: e questa indicazione è perseguibile nella maggior parte dei progetti odierni. Poiché l'integrazione continua richiede commit frequenti, risparmiare tempo in fase di commit può restituire agli sviluppatori molto tempo.

Il miglioramento è un processo. Quando i team cambiano il modo in cui affrontano gli errori, si crea un cambiamento culturale che porta a un miglioramento continuo. Invece di chiedere chi ha causato l'errore, chiedi cosa lo ha causato. Questo aiuta a passare da una cultura della colpevolizzazione ad una cultura dell'apprendimento.

Se i team eseguono commit frequenti, diventa molto più facile individuare i problemi e risolverli. Se ci sono pattern ricorrenti nelle build non andate a buon fine, è bene analizzarne le cause. Ci sono errori non relativi al codice che innescano le build inutilmente? È possibile incorporare un parametro allow_failure. Cerca modi per migliorare continuamente, senza colpevolizzare nessuno per gli errori ma cercandone le cause.

Nell'integrazione continua, ogni commit attiva una build. Queste build eseguono quindi dei test per capire se l'introduzione di modifiche al codice sta generando anche degli errori. La piramide di test è un modo per valutare il bilanciamento dei test.  Il test end-to-end viene utilizzato principalmente come salvaguardia, mentre i test unitari sono usati principalmente per individuare gli errori. Una cosa importante da tenere a mente durante i test è l'ambiente. Quando gli ambienti di test e produzione coincidono, gli sviluppatori possono fare affidamento sui risultati ed eseguire deployment in sicurezza.

In GitLab, Review Apps consente di inserire il nuovo codice in un ambiente live simile a quello di produzione per visualizzarne le modifiche. Questa funzionalità aiuta gli sviluppatori a valutare l'impatto delle modifiche.

L'integrazione continua consente di eseguire deployment più velocemente e di ricevere un feedback più tempestivamente. In definitiva, il miglior sistema di integrazione continua è quello che usi realmente. Trova la CI giusta per le tue esigenze e segui queste best practice per sfruttare al meglio il tuo nuovo flusso di lavoro CI.

Adottando le best practice illustrate, i team di sviluppo software, inclusi i team di platform engineering e i team di DevOps, possono migliorare le attività di integrazione continua, semplificando di conseguenza il processo di sviluppo e deployment. Man mano che queste pratiche diventano più radicate nell'ambiente di sviluppo, si perfeziona anche l'allineamento tra gli obiettivi del team tecnico e l'esecuzione operativa.

Ricorda che un sistema di integrazione continua efficace non è tale solo per gli strumenti, ma anche per il modo in cui questi vengono utilizzati dal team per stimolare il miglioramento e ottenere risultati rapidi e affidabili.