Git CI/CD: 5 consigli per repository Git compatibili con la CI

Un sistema di archiviazione esterno come Artifactory (che crea un add-on per Bamboo), Nexus o Archiva può aiutarti per gli artefatti generati dal tuo team o dai team intorno a te. I file di cui hai bisogno possono essere inseriti nella directory della build a inizio compilazione, come le librerie di terze parti che inserisci tramite Maven o Gradle.

Se non hai già un sistema di archiviazione esterno sulla tua rete, è più facile sfruttare il supporto per file di grandi dimensioni (Large, File Support, FS) di Git.

Git LSF è un'estensione che memorizza i puntatori a file di grandi dimensioni nel tuo repository, invece di archiviare i file stessi. I file vengono archiviati su un server remoto. Come puoi immaginare, questo riduce drasticamente il tempo di clonazione.

È probabile che tu abbia già accesso a Git LFS, sia Bitbucket che Github lo supportano.

Ma supponiamo che la tua build richieda la cronologia completa del repository, se, ad esempio, uno dei passaggi della tua build aggiorna il numero di versione nel POM (o simile), o stai eseguendo il merge di due branch per ogni build. Entrambi i casi richiedono che Bamboo reinvii le modifiche al tuo repository.

Con Git, è possibile eseguire il push di semplici modifiche ai file (come l'aggiornamento del numero di versione) senza che sia presente l'intera cronologia. Ma il merge richiede ancora la cronologia del repository, perché Git deve tornare all'antenato comune dei due branch, cosa che potrebbe costituire un problema se la tua build utilizzasse una clonazione superficiale. Questo porta al consiglio n. 3.

Questo rende anche l'operazione di clonazione molto più veloce e Bamboo si occupa di questa operazione per impostazione predefinita.

Tieni presente che la memorizzazione del repository nella cache è utile solo se utilizzi agenti persistenti da una build all'altra. Se crei e rimuovi gli agenti di compilazione su EC2 o un altro provider cloud ogni volta che viene eseguita una build, la memorizzazione del repository nella cache non avrà importanza perché lavorerai con una directory di compilazione vuota e dovrai comunque recuperare una copia completa del repository ogni volta.

Cloni superficiali più memorizzazione del repository nella cache, divisi per agenti persistenti ed agenti elastici, equivalgono a un'interessante rete di fattori. Ecco una piccola matrice per aiutarti a elaborare strategie.

Inutile (quasi) dire quanto eseguire una pipeline di CI su tutti i branch attivi sia una buona idea. Ma è una buona idea eseguire tutte le build su tutti i branch rispetto a tutti i commit? Probabilmente no. Ecco perché.

Prendiamo Atlassian, per esempio. Abbiamo più di 800 sviluppatori, ognuno dei quali esegue il push di modifiche al repository più volte al giorno, per lo più ai branch di funzioni. Sono un sacco di build. E a meno che tu non intenda ridimensionare gli agenti di compilazione all'istante e all'infinito, significa molta attesa in coda.

Uno dei nostri server interni Bamboo ospita 935 piani di compilazione diversi. Abbiamo collegato 141 agenti di compilazione a questo server e utilizzato best practice quali il passaggio degli artefatti e la parallelizzazione dei test per rendere ogni build il più efficiente possibile. E ancora: eseguire compilazioni dopo ogni singolo push stava bloccando i flussi di lavoro.

Invece di configurare semplicemente un'altra istanza Bamboo con altri 100 agenti, abbiamo fatto un passo indietro e ci siamo chiesti se fosse davvero necessario. E la risposta era no.

Quindi abbiamo fornito agli sviluppatori la possibilità di attivare la compilazione dei loro branch tramite un pulsante e non automaticamente. È un buon modo per bilanciare il rigore dei test con la conservazione delle risorse e i branch sono il luogo in cui avviene la maggior parte delle attività di modifica, quindi l'opportunità di risparmio è notevole.

A molti sviluppatori piace il controllo aggiuntivo offerto dalle compilazioni tramite pulsante e le trovano particolarmente adatte al loro flusso di lavoro. Altri preferiscono non pensare a quando eseguire una build e attenersi ai trigger automatici. Entrambi gli approcci possono funzionare. L'importante è testare i due branch in primo luogo e assicurarsi che la compilazione sia pulita prima di eseguire il merge upstream.

I branch fondamentali come i branch dei rilasci principale e stabile sono un discorso a parte. Le compilazioni vengono attivate automaticamente, interrogando il repository per le modifiche o inviando una notifica push da Bitbucket a Bamboo. Dato che utilizziamo i branch di sviluppo per tutti i nostri lavori in corso, gli unici commit che entrano in un repository principale (in teoria) dovrebbero essere branch di sviluppo di cui viene eseguito il merge. Inoltre, queste sono le righe di codice da cui viene eseguito il rilascio e da cui vengono creati i nostri branch di sviluppo. Quindi è davvero importante ottenere risultati dei test tempestivi per ogni merge.

Eseguire il polling del repository ogni pochi minuti per cercare eventuali modifiche è un'operazione piuttosto economica per Bamboo. Ma quando arrivi a centinaia di build contro migliaia di branch, che coinvolgono dozzine di repository, il numero cresce in modo esponenziale. Invece di effettuare tutte queste operazioni di polling con Bamboo, puoi fare in modo che Bitbucket esegua una chiamata quando viene eseguito il push di una modifica, che deve essere compilata.

In genere, ciò avviene aggiungendo un hook al tuo repository, ma guarda caso, l'integrazione tra Bitbucket e Bamboo esegue tutte le configurazioni sottostanti per te. Una volta collegati sul back-end, la build basata su repository attiva Just Work™ immediatamente. Non sono richiesti hook o configurazioni speciali.

Indipendentemente dagli strumenti, i trigger basati sui repository hanno il vantaggio di disattivarsi automaticamente quando il branch di destinazione diventa inattivo. In altre parole, non sprecherai mai i cicli della CPU del tuo sistema di CI interrogando centinaia di branch abbandonati. Non dovrai nemmeno disattivare manualmente le build dei branch. (Anche se vale la pena notare che Bamboo può essere facilmente configurato per ignorare i branch dopo X giorni di inattività, se preferisci ancora il polling.)