Close

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

Preparati per il successo: tutto inizia dal tuo repository.

Primo piano di Sarah Goff Du-Pont
Sarah Goff-Dupont

Principal Writer


Git e continuous delivery sono una combinazione più unica che rara nel mondo del software: due ottimi elementi che insieme diventano eccezionali. Quindi voglio condividere alcuni suggerimenti per far sì che le tue build in Bamboo funzionino bene con i tuoi repository Bitbucket. La maggior parte della loro interazione avviene nelle fasi di compilazione e test della continuous delivery, quindi noterai che parlo principalmente in termini di "CI", invece di "CD".

1: Archivia file di grandi dimensioni al di fuori del tuo repository


Su Git si sente spesso che sarebbe meglio evitare di immettere file di grandi dimensioni nel proprio repository: file binari, file multimediali, artefatti archiviati, ecc. Questo perché una volta aggiunto un file, questo sarà sempre presente nella cronologia del repository, il che significa che ogni volta che il repository viene clonato, verrà clonato anche quel file enorme e pesante.

Estrarre un file dalla cronologia del repository è complicato: è l'equivalente di eseguire una lobotomia frontale alla tua codebase. E questa estrazione chirurgica di file altera l'intera cronologia del repository, così da non avere più un quadro chiaro di quali modifiche siano state apportate e quando. Tutti buoni motivi per evitare file di grandi dimensioni come regola generale. E...

Tenere i file di grandi dimensioni lontano dai tuoi repository Git è particolarmente importante per la CI.

A ogni compilazione, il server di CI deve clonare il tuo repository nella directory della build funzionante. E un repository pieno di enormi artefatti rallenta il processo e aumenta il tempo di attesa per i risultati della build.

Ok, bene. Ma cosa succede se la tua build dipende da file binari di altri progetti o da artefatti di grandi dimensioni? Questa è una situazione molto comune, e probabilmente lo sarà sempre. Quindi la domanda è: come possiamo gestirla in modo efficace?

Scopri la soluzione

Creare e gestire software con Open DevOps

Materiale correlato

Informazioni sullo sviluppo basato su trunk

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.

Suggerimento: se gli artefatti cambiano frequentemente, evita la tentazione di sincronizzare i tuoi file di grandi dimensioni con il server di compilazione ogni notte, in modo da trasferirli sul disco solo al momento della compilazione. Le sincronizzazioni notturne finiranno per creare versioni obsolete degli artefatti su cui verranno eseguite compilazioni. Inoltre, gli sviluppatori hanno comunque bisogno di questi file per le build sulle loro workstation locali. Quindi, nel complesso, la cosa più semplice da fare è far sì che il download degli artefatti faccia parte della build.

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.

Git LSF

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

2: Usa cloni superficiali per la CI


A ogni esecuzione della build, il server di compilazione clona il repository nella directory di lavoro corrente. Come ho detto prima, quando Git clona un repository, duplica tutta la cronologia del repository per impostazione predefinita. Quindi col tempo questa operazione richiederà sempre più tempo.

Con cloni superficiali, verrà rimossa solo l'istantanea corrente del tuo repository. Quindi può essere molto utile per ridurre i tempi di compilazione, soprattutto quando si lavora con repository di grandi dimensioni e/o meno recenti.

Screenshot di repository Git

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.

3: Memorizza nella cache il repository sugli agenti di compilazione


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.

Screenshot agenti persistenti e agenti elastici

4: Scegli i trigger in modo ponderato


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.

miniatura dei trigger continui

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.

5: No al polling e sì all'hooking


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.

Screenshot configurazione Bitbucket

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.)

La chiave per usare Git con la CI è...


...simply being thoughtful. All the things that worked great when you were doing CI with a centralized VCS? Some of them will work less great with Git. So check your assumptions – that's the first step. For Atlassian customers, the second step is integrating Bamboo with Bitbucket. Check out our documentation for details, and happy building!

Sarah Goff-Dupont
Sarah Goff-Dupont

Sarah è un QA Engineer diventata scrittrice il cui lavoro è stato pubblicato su Harvard Business Review, Inc., Huffington Post e in pubblicazioni di settore. Lavora a distanza da casa sua in Minnesota e le piace ogni minuto. Quando non scrive, puoi trovarla a leggere, fare snowboard, cucinare e/o scambiare giochi di parole ridicoli con i suoi figli.

Contatta Sarah su LinkedIn


Condividi l'articolo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Leggi il blog

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up