Superkrachtige continue levering met Git

Eerlijk gezegd is het niet zo dat Git op zichzelf zo perfect is voor continue levering. De branching-workflows zijn geweldig voor CD en Git is geweldig voor branching-workflows. Naast het feit dat 'branch-and-merge'-workflows uitstekend samengaan met CD's, kun je er ook lastige bugs mee aanpakken, nieuwe technologieën proberen, of je kunt gewoon beginnen met het coderen van een nieuwe functie zonder het risico te lopen dat je teamgenoten door je wijzigingen van hun eigen taken worden gehouden.

Het is duidelijk dat je met Subversion en andere traditionele versiebeheersystemen ook kunt branchen. Maar laten we even pas op de plaats maken en kennis maken met het slechte evenbeeld van branching: de samenvoeging.

Traditionele versiebeheersystemen zoals Subversion zijn gewoon niet zo goed in het traceren van versies van bestanden die zich in verschillende branches bevinden, en als het tijd is om bestanden samen te voegen, moet Subversion vaak stoppen en om een locatie vragen. (Je weet wel ... dat kleine pop-upvenster met de vraag 'Wil je deze regel of die regel in de samengevoegde versie?') Het feit dat er tijdens samenvoegingen zoveel menselijke interactie nodig is, stimuleert teams om de code te bevriezen, zodat degene die de samenvoeging uitvoert niet wordt gestoord door nieuwe veranderingen die zich in een van de branches voordoen. En het bevriezen van codes is duur: het veroorzaakt een onproductieve tijd.

Git daarentegen is heel goed in het bijhouden van veranderingen in verschillende versies van bestanden die zich in verschillende branches bevinden, en het weet altijd hoe de oudere versie van dat bestand eruitzag. Het heeft dus in feite een ingebouwde GPS waarmee deze samenvoegingen kan navigeren zonder dat die hoeft te stoppen en je steeds om een locatie hoeft te vragen.

Met Git ben je vrij om de kracht van branching te benutten op een manier die onpraktisch zou zijn met Subversion. De kosten die gepaard gaan met branching en samenvoegingen zijn zo onbeduidend dat branches die slechts een dag of twee bestaan, niet alleen haalbaar zijn, maar ook nuttig zijn.

Oké, prima. Maar wat maakt branching eigenlijk zo krachtig voor continue levering?

Bijvoorbeeld: alle ontwikkelingsteams van Atlassian hebben een overeenkomst dat niets ooit rechtstreeks naar de main-branch of de stabiele branches wordt gecommit. Iedereen doet zijn werk in branches. We zijn zelfs zo optimistisch over branches dat we een aparte branch aanmaken voor elk Jira-issue die we behandelen. Daarover straks meer.

Hoe dan ook, dit betekent dat mensen zoveel tests kunnen doen en zoveel schade kunnen aanrichten aan hun branches als ze willen! De main-branch bevindt zich in een staat van waaruit je kunt releasen en waarin je nieuwe branches kunt aanmaken zonder een hoop gebroken code te erven. Dat is een overwinning voor CD en de algemene productiviteit van ontwikkelaars (om nog maar te zwijgen van het moreel).

Branches helpen je om bijdragen van buiten het team te accepteren

De mogelijkheid van Git voor branching, en vooral voor het vertakken van complete repo's, maakt het eenvoudig om bijdragen te ontvangen van mensen buiten het directe team: aannemers, ontwikkelaars van partnerbedrijven, ontwikkelaars van andere bedrijfseenheden, enz. Je hoeft je geen zorgen te maken over mensen die niet bekend zijn met je codebasis die zomaar wijzigingen aanbrengen in kritieke branches en dus je mogelijkheid om nieuwe code te leveren belemmeren.

Ook hier zijn rigoureuze geautomatiseerde tests in hun branches of vertakte repo's de sleutel tot een goede samenwerking. Je moet hun build- en testresultaten bekijken voordat je samenvoegingen in de codelijn van de main goedkeurt.

Branching goed uitgevoerd = duidelijkheid over het project

Nu populair: maak een ontwikkelingsbranch aan voor elke story, bugfix en taak (d.w.z. elke JIRA-issue) die je implementeert. We hebben dit model van branch-per-issue bij Atlassian jaren geleden overgenomen, en we hebben van die beslissing geen spijt gehad! Het is ook populair geworden onder onze klanten.

Door voor elke issue een branch aan te maken, kun je eenvoudig zelf kiezen welke wijzigingen je wilt leveren aan de productie of in een release wilt bundelen. Aangezien je veranderingen niet zomaar in de main-branch kunt opstapelen, kun je selecteren wat er in de main-branch komt en wanneer dit gebeurt. Je kunt een MVP van een epic verzenden plus één nice-to-have, in plaats van te wachten tot alle nice-to-haves volledig klaar zijn. Of lever een enkele bugfix en doe dat in het kader van een gewone oude release. Zelfs als de oplossing dringend is, hoef je niet door hoepels te springen door andere wijzigingen terug te draaien die nog niet klaar zijn voor levering om alleen die oplossing door te kunnen zetten.

En dat gemak waarmee een codewijziging kan worden verzonden, is de essentie van continue levering.

Deze aanpak zorgt er niet alleen voor dat onbewezen code van de main-branch wordt verwijderd. Als je echter in de naam van de branch de relevante Jira-issuesleutel en de naam of initialen van de ontwikkelaar vermeldt, is het glashelder wat de stand van zaken is voor elke issue.

Let op de naamgevingsconventie die in de afbeelding hierboven wordt gebruikt: het is de unieke code voor de JIRA-issue die wordt geïmplementeerd, plus een korte, voor mensen leesbare beschrijving van waar die issue allemaal over gaat. Dus als releasemanager of andere belanghebbende zou je naar de hierboven getoonde repo kunnen kijken en in één oogopslag weten dat de userstory van AMKT-13952 klaar is voor publicatie, omdat je kunt zien dat het is samengevoegd in de main. Dat is traceerbaarheid zonder al het handmatige werk.

Ik ben blij dat je het vraagt! Ik zal deze hier even snel doornemen, aangezien andere artikelen op deze site dieper ingaan op elke fase.

• Maak een branch aan voor de issue waar je aan gaat werken. Vermeld de Jira-issuesleutel in de naam van de branch, zodat het duidelijk is wat de functie van de branch is. Als je andere tools van Atlassian gebruikt, zoals Bitbucket en Bitbucket Pipelines, dan pakken ze die issue op en leggen ze verbanden tussen de issue, je branch, al je commits, je builds, je pull requests en je implementaties die gekoppeld zijn aan die issue. Met andere woorden, de issuesleutels zijn magisch.
• Breng je wijzigingen aan in de branch. Je bevindt je hier in je eigen wereldje, dus ga helemaal los. Probeer nieuwe dingen. Maak dingen kapot. Het maakt niet uit, want je zult ook ...
• Je branch onder CI zetten. Het is aan jou en je team om te beslissen of je hier gespecialiseerde tests zoals belastingtests of end-to-end UI-tests wilt uitvoeren, en of er automatisch een testrun wordt gestart telkens je wijzigingen pusht naar je branch. De teams van Atlassian voeren over het algemeen tests op unit- en integratieniveau uit in ontwikkelingsbranches.
• Werk je branch regelmatig bij met de laatste updates van de main-branch. Je kunt rebase of branch-commit gebruiken om dit te bereiken. Het is helemaal aan jou. (Maar vergeet niet om een branch die je deelt met andere ontwikkelaars niet opnieuw te rebasen, daar worden ze chagrijnig van.) Hoe dan ook, je zult integratieconflicten ontdekken voordat je samenvoegt, wat weer helpt om de main-branch netjes te houden.
• Maak een pull request aan wanneer je klaar bent om samen te voegen. Dit betekent dat de implementatie is voltooid, dat je wijzigingen van je teamgenoten hebt ingevoerd en eventuele conflicten hebt afgesloten, en dat je branch voor alle tests slaagt.
• Samenvoegen en wanneer je wilt implementeren. Sommige teams geven er de voorkeur aan om elke wijziging automatisch te leveren zodra deze is samengevoegd met de hoofdbranch en als alle tests daar geslaagd zijn. Dit is het model voor continue implementatie. Andere teams laten liever een mens handmatig beslissen over welke wijzigingen ze leveren en wanneer dit gebeurt. Dat is aan jou en je team.

Dus dat is het. Branching-workflows maken continue levering eenvoudiger, en Git neemt de zorgen over branches weg. Lees verder voor meer informatie over je Git-repository instellen zodat deze geschikt is voor CD en hoe je al deze ideeën in de praktijk kunt brengen met je Atlassian-tools. Tot op de volgende pagina!