CI/CD Git: 5 tips voor CI-vriendelijke Git-repo's

Een extern opslagsysteem zoals Artifactory (dat een add-on maakt voor Bamboo), Nexus of Archiva kan helpen bij artefacten die worden gegenereerd door je team of de teams om je heen. De bestanden die je nodig hebt, kunnen aan het begin van je build naar de build-directory worden gehaald, net als de bibliotheken van derden via Maven of Gradle.

Als je nog geen extern opslagsysteem op je netwerk hebt, is het het gemakkelijkst om te profiteren van Git Large File Support (LFS).

Git LFS is een extensie die pointers bewaart naar grote bestanden in je repository, in plaats van de bestanden zelf daar op te slaan. De bestanden zelf worden opgeslagen op een externe server. Zoals je je kunt voorstellen, verkort dit de tijd om te klonen aanzienlijk.

De kans is groot dat je al toegang hebt tot Git LFS – zowel Bitbucket als Github ondersteunen dit.

Maar stel dat je voor je build de volledige repogeschiedenis nodig hebt, bijvoorbeeld als in een van de stappen in je build het versienummer in je POM (of iets dergelijks) wordt bijgewerkt, of als je bij elke build twee branches samenvoegt. In beide gevallen is Bamboo nodig om wijzigingen te terug te pushen naar je repo.

Met Git kunnen eenvoudige wijzigingen in bestanden (zoals het updaten van een versienummer) worden doorgevoerd zonder dat de volledige geschiedenis aanwezig is. Maar voor mergen is nog steeds de geschiedenis van de repo nodig, want Git moet terugkijken en de gemeenschappelijke voorouder van de twee branches vinden – dat zal een probleem vormen als je build gebruikmaakt van oppervlakkig klonen. Dit brengt me op tip #3.

Dit maakt het klonen ook veel sneller, en Bamboo doet dit zelfs standaard.

Houd er rekening mee dat repocaching je alleen ten goede komt als je agents gebruikt die van build tot build blijven bestaan. Als je buildagents aanmaakt en afbreekt elke keer dat een build draait op EC2 of een andere cloudprovider, maakt repocaching niet uit, omdat je dan met een lege build-map werkt en hoe dan ook elke keer een volledige kopie van de repo moet pullen.

Ondiepe klonen, plus repocaching, gedeeld door persistente versus elastische agents, komt uit op een interessant web van factoren. Hier is een kleine matrix om je te helpen bij het bepalen van je strategie.

Het spreekt (bijna) voor zich dat het een goed idee is om CI in al je actieve branches te gebruiken. Maar is het een goed idee om alle builds op alle branches met alle commits uit te voeren? Waarschijnlijk niet. Hier lees je waarom.

Neem bijvoorbeeld Atlassian. We hebben meer dan 800 ontwikkelaars, die elk meerdere keren per dag wijzigingen naar de repo pushen — meestal pushen ze naar hun eigen functie-branches. Dat zijn behoorlijk wat builds. En tenzij je je buildagents onmiddellijk en oneindig schaalt, betekent dat veel wachten in de rij.

Een van onze interne Bamboo-servers biedt plaats aan 935 verschillende build-plannen. We hebben 141 buildagents op deze server aangesloten en aanbevolen werkwijzen gebruikt, zoals het doorsturen van artefacten en parallellisatie van tests om elke build zo efficiënt mogelijk te maken. Toch werd het systeem door iedere push vertraagd.

In plaats van simpelweg nog een Bamboo-instantie op te zetten met nog eens 100 agents, deden we een stap terug en vroegen we ons af of dit echt nodig was. En het antwoord was nee.

Daarom gaven we de ontwikkelaars de optie om te kiezen of ze de build van hun branch wilden activeren, in plaats van deze altijd automatisch te activeren. Het is een goede manier om rigoureus testen af te stemmen op de beschikbare hulpbronnen, in branches vinden de meeste veranderingen plaats, dus daar zijn de mogelijkheden om te besparen.

Veel ontwikkelaars houden van de extra controle die deze keuzevrijheid biedt en binden dat dit op natuurlijke wijze in hun workflow past. Anderen denken liever niet na over wanneer ze een build moeten uitvoeren en houden het bij automatische triggers. Beide werkwijzen kunnen werken. Het belangrijkste is om je branches überhaupt te testen en ervoor te zorgen dat je een schone build hebt voordat je deze samenvoegt.

Kritieke branches, zoals de hoofd-branch en de branches van stabiele releases, zijn echter een ander verhaal. Deze builds worden automatisch geactiveerd, ofwel door in de repo te vragen naar wijzigingen, ofwel door een pushmelding van Bitbucket naar Bamboo te sturen. Aangezien we ontwikkelaars-branches gebruiken voor al ons werk in uitvoering, zouden (in theorie) de enige commits naar de hoofdversie moeten bestaan uit ontwikkelaars-branches die worden samengevoegd. Daarnaast zijn dit de coderegels die we releasen en waar we onze ontwikkelaars-branches van maken. Het is dus echt belangrijk dat we voor elke samenvoeging tijdig testresultaten krijgen.

Iedere paar minuten een poll uitvoeren in je repo om op zoek te gaan naar wijzigingen is een vrij goedkope operatie voor Bamboo. Maar als je opschaalt naar honderden builds tegen duizenden branches met tientallen repo's, loopt het snel op. In plaats van Bamboo te belasten met al die polls, kun je Bitbucket laten aangeven wanneer er een wijziging is doorgevoerd en moet worden doorgevoerd.

Meestal doe je dit door een hook toe te voegen aan je repository, maar toevallig regelt de integratie tussen Bitbucket en Bamboo alles al achter de schermen. Zodra ze achter de schermen zijn gekoppeld, activeert een repo-gestuurde build Just Work™ automatisch. Geen hooks of speciale configuraties nodig.

Ongeacht de tools hebben repo-gestuurde triggers het voordeel dat ze automatisch verdwijnen de doel-branch inactief wordt. Met andere woorden, je zult nooit de CPU-cycli van je CI-systeem verspillen aan honderden verlaten branches. Ook bespaar je jezelf tijd door branches niet handmatig uit te hoeven zetten. (Het is het benomen waard dat Bamboo eenvoudig kan worden geconfigureerd om branches te negeren na X dagen inactiviteit, als je nog steeds de voorkeur geeft aan polls.)