Close

Superkrachtige continue levering met Git

Nu Git de problemen van samenvoegen heeft opgelost, zijn branchingworkflows veel aantrekkelijker.

Sarah Goff Du-Pont headshot
Sarah Goff-Dupont

Hoofdschrijver


We hebben allemaal wel eens gehoord van 'pas op voor de code die maar door één persoon is geschreven'. We weten ook wat de voordelen zijn van het ontwikkelen van software in teamverband: je krijgt verschillende manieren van denken, verschillende achtergronden en ervaringen ... en als je die verschillen gebruikt voor welk probleem je ook probeert op te lossen, krijg je uiteindelijk betere software. Het is beter te onderhouden, van hogere kwaliteit en is uiteindelijk beter voor de gebruiker.

Teamsamenwerking | Atlassian CI/CD

Maar dan is er nog iets dat we weten: het kan lastig zijn om je als team te ontwikkelen!

Je probeert te begrijpen aan welke delen code iedereen werkt, je probeert ervoor te zorgen dat wijzigingen niet met elkaar in conflict zijn, je probeert defecten op te sporen voordat je klanten dat doen, en je probeert iedereen die betrokken is bij het project op de hoogte te houden van de voortgang. Het blijkt dat elk van deze problemen wordt aangepakt door middel van Git-branching of continue levering.

Ik hoop je ervan te overtuigen dat je een superkrachtig recept voor succes hebt, door die twee te combineren (misschien kun je voor de lol ook nog wat geweldige tools toevoegen).

De kracht van branchgebaseerde workflows


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.

Eenvoudig workflowschema | Atlassian CI/CD

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?

Branches houden de main-branch opgeruimd en releasebaar

We hebben vastgesteld dat branches op korte duur een geweldige manier bieden voor ontwikkelaars om samen te werken aan een project of functie zonder dat ze elkaar in de weg zitten. Maar wat echter nog belangrijker is voor CD, door al het werk in uitvoering in ontwikkelingsbranches te isoleren blijven de main-branch en alle stabiele branches opgeruimd, zodat je op elke moment kunt leveren.

Dit betekent dat je een hele reeks geautomatiseerde tests moet uitvoeren op dev-branches, zodat ontwikkelaars sterke signalen krijgen over de kwaliteit van hun code en zelfverzekerde beslissingen kunnen nemen over wanneer hun wijzigingen klaar zijn om te worden samengevoegd. (Als je geautomatiseerde tests nog niet geweldig vindt, bekijk dan dit bericht van RebelLabs voor een ludieke preek en recepten voor het schrijven van je eerste unittests.)

Het betekent ook dat je de pull requests van Git moet gebruiken als een vorm van codebeoordeling, zodat je hele team vertrouwen heeft in de onderhoudbaarheid van de code en interoperabiliteit met andere delen van de codebasis. Ja, hierbij is inderdaad meer werk vooraf nodig dan bij traditionele leveringsmodellen. En ja, het is de moeite waard.

Oplossing bekijken

Software bouwen en gebruiken met Open DevOps

Gerelateerd materiaal

Wat is de DevOps-pipeline?

Een succesvolle continue levering betekent dat je releasebranches georganiseerd blijven

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.

Schermafbeelding van Bitbucket commits git repo | Atlassian CI/CD

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.

Dus hoe werkt de Git + workflow voor continue levering?


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.
Git CI-automatisering | Atlassian CI/CD

De conclusie ...


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!

Sarah Goff-Dupont
Sarah Goff-Dupont

Sarah is een QA-engineer die schrijver is geworden wiens werk in Harvard Business Review, Inc., Huffington Post en branchepublicaties gestaan heeft. Ze werkt op afstand vanuit haar huis in Minnesota en geniet van elke minuut. Als ze niet aan het schrijven is, is ze aan het lezen, snowboarden, koken en/of wisselt ze flauwe woordspelingen uit met haar kinderen.

Maak een connectie met Sarah op LinkedIn


Deel dit artikel

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Toelichting DevOps

DevOps-community

Afbeelding van kaart

Gratis aan de slag

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up