Deepdive in Git workflows

Auteur
Sieger Veenstra
Datum

De alternatieven voor GitFlow

GitFlow is de meest gebruikte workflow strategie voor gebruik van het versiebeheersysteem Git. Veel gehoorde kritiek op GitFlow is dat het in veel gevallen complexer is dan noodzakelijk. Op de technology radar van Thoughtworks staat GitFlow bijvoorbeeld op 'Hold'. Er zijn een aantal alternatieven voor GitFlow zoals GitHub Flow en GitLab Flow die specifiek gericht zijn op een bepaalde werkwijzen die daardoor een versimpeling in de werkwijze mogelijk maken.

Versiebeheer met Git maakt het erg eenvoudig om branches aan te maken en deze ook weer te mergen. Git kan in de meeste gevallen volledig automatisch mergen. Dit zijn belangrijke verbeteringen ten opzicht van ouder versiebeheersystemen, zoals bijvoorbeeld CVS en Subversion. Om hier optimaal gebruik van te kunnen maken is het belangrijk om afspraken te maken over de werkwijze. Denk hierbij bijvoorbeeld aan: wanneer je in het ontwikkelproces een branch aanmaakt, en hoe je deze noemt. Het geheel van deze afspraken noemen we een workflow of branching strategie.

De meeste workflow strategieën maken onderscheid tussen “vast” en “tijdelijke” branches. Een vaste branch blijft altijd bestaan, terwijl een tijdelijke branch na een tijdje weer wordt opgeheven, nadat deze gemerged is met één (of meer) van de vaste branches. Een tijdelijke branch wordt ook wel een “feature” of “topic” branch genoemd.

GitFlow

De Git documentatie beschrijft al een aantal mogelijke workflows, maar deze gaan niet concreet in op praktische zaken zoals het maken van een release of een hotfix. GitFlow was één van de eerste uitwerking van een Git workflow die dit wel doet. Deze workflow is in 2010 uitgewerkt door de Nederlander Vincent Driessen. Nog steeds is GitFlow de meest bekend workflow. Zo is ondersteuning voor GitFlow ingebouwd in sommige Gitclients, zoals SourceTree en GitKraken.

GitFlow werkt met 2 vaste branches “master” en “develop”. De “master” branch bevat de productieversie van de code en “develop” bevat de development versie van de code.

Git 1 Er wordt gebruik gemaakt van 3 soorten tijdelijke branches:

  • Feature branches voor de ontwikkeling van nieuwe functionaliteit. Deze worden afgesplitst van “develop” en ook weer teruggemerged in “develop”.
  • Release branches voor bugfixing en bijvoorbeeld het aanpassen van versienummers. Release branches worden afgesplitst van “develop” en worden zowel naar “develop” als “master” gemerged.
  • Hotfix branches voor spoedfixes in productie. Deze worden afgesplitst van de “master” en gemerged naar zowel “master” als “develop”.

GitHub Flow

Een nadeel van bovenstaande GitFlow model is dat het niet goed aansluit bij de uitgangspunten van continuous delivery en continuous deployment.

Bij continuous deployment wordt elke wijziging, die door het geautomatiseerde testproces is goedgekeurd automatisch naar productie gedeployed. Organisaties die werken volgens continuous deployment deployen dus vele malen per dag naar productie. Etsy deployed bijvoorbeeld 50 keer per dag naar productie.

Continuous delivery iets minder ver. In principe moet de code elk moment naar productie gedeployed kunnen worden, maar dit gebeurd niet volledig automatisch. Organisaties die werken met continuous delivery deployen bijvoorbeeld 1 keer per dag of 1 keer per week naar de productie omgeving.

De aanpak vak van GitFlow met een aparte “develop”, “master” en “release” branches sluit slecht aan bij een aantal belangrijke principes achter continuous delivery. Zoals “Every Check-in Leads to a Potential Release” en “Only Build Your Binaries Once”. Speciaal voor continuous delivery en continuous deployment is GitHub Flow ontwikkeld. Deze workflow is veel simpeler dan GitFlow.

GitHub Flow kent maar één vast branch: “master”. Ontwikkeling van nieuwe functionaliteit vindt plaats op een tijdelijke branch, als de ontwikkeling is afgerond, inclusief tests en reviews, wordt de tijdelijke branch gemerged naar “master”. Hierna kan de “master” branch (automatisch) gedeployed worden.

Git 2

GitHub Flow lijkt sterk op de Simple Git Workflow van Atlassian.

GitLab Flow

GitHub flow is dus specifiek geschikt voor continuous delivery of continuous deployment scenario’s. GitLab flow wil een simpeler alternatief bieden voor GitFlow dat ook in andere situaties toepasbaar is. Er zijn 2 varianten van GitLab Flow: ‘GitLab Flow with release branches’ en ‘GitLab Flow with environment branches’.

GitLab Flow with release branches

‘GitLab Flow with release branches’ is vooral bedoelt vooral projecten waarbij software naar buiten wordt opgeleverd. Denk bijvoorbeeld aan een softwarepakket dat verkocht is aan meerdere klanten of aan een mobiele app. Er wordt uitgegaan van Semantic Versioning.

Ontwikkeling gebeurde zoveel mogelijk op de “master” branch. Daarnaast wordt voor elke release een vaste “release” branch aangemaakt. Deze “release” branch heet naar het MAJOR.MINOR versienummer van de release, bijvoorbeeld ‘2-4-stable’. De eerste versie op deze branch is dan bijvoorbeeld 2.4.0 en bij de eerste bugfix wordt dat vervolgens 2.4.1. Het is slim om zo lang mogelijk te wachten met het aanmaken van de “release” branch, zodat de hoeveelheid werk die zowel op de “master” als op de “release” branch moet worden doorgevoerd minimaal is.

Git 3

Bugfixes worden altijd ontwikkeld op de “master” branch en vandaar eventueel als ‘Cherry pick’ overgenomen op de “release” branch. Hierdoor weet je zeker dat een opgeloste bug niet terugkeert in een nieuwe release.

GitLab Flow with environment branches

‘GitLab Flow with release branches’ is vooral gericht op meer traditionele web ontwikkeling (geen continuous delivery) die werkt met een OTAP-model (Ontwikkel, Test, Acceptatie en Productie).

Ontwikkeling van nieuwe functionaliteit vindt plaats op een tijdelijke branch, als de ontwikkeling is afgerond, inclusief tests en reviews, wordt de tijdelijke branch gemerged naar “master”. De “master” branch wordt vervolgens automatisch gedeployed op een test omgeving.

Daarnaast zijn er aparte branches voor de volgende omgevingen. Als je naast de test omgeving ook een acceptatie en productie omgeving kent, dan is er dus ook een “acceptatie” en een “productie” branch. Als wijzigingen vanuit “master” naar “acceptatie” worden gemerged, moet je continuous integration server hierna automatische een deploy triggeren naar de acceptatie omgeving. Hetzelfde moet gebeuren bij een merge van “acceptatie” naar “productie”. Git 4

Conclusie

Er is meer dan alleen GitFlow! Naast GitFlow zijn er nog verschillende andere workflows die vaak simpeler in gebruik zijn. Deze andere workflows richten zich vaak op een specifieke werkwijze.

GitFlow is geen goede match als je continuous delivery wilt toepassen. GitFlow sluit slecht aan bij een aantal belangrijke principes achter continuous delivery, zoals “Every Check-in Leads to a Potential Release” en “Only Build Your Binaries Once”. Er zijn andere workflows die zich wel specifiek richten op continuous delivery.

Ook als je geen continuous delivery wilt of kunt toepassen, bijvoorbeeld omdat je mobiele apps ontwikkeld, zijn er eenvoudigere alternatieven voor GitFlow, bijvoorbeeld ‘GitLab Flow with release branches’.

Tags

Continuous Deployment