Bijna alle versiebeheersystemen steunen tegenwoordig branches: onafhankelijke werklijnen die voortkomen uit één centrale codebase. Afhankelijk van je versiebeheersysteem kan de hoofdbranch mainline, standaard of trunk worden genoemd. Ontwikkelaars kunnen hun eigen branches maken vanaf de hoofdcoderegel en er onafhankelijk naast werken.
Waarom branches gebruiken?
Met branching kunnen teams van ontwikkelaars eenvoudig samenwerken binnen één centrale codebase. Wanneer een ontwikkelaar een branch maakt, maakt het versiebeheersysteem op dat moment een kopie van de codebase. Wijzigingen in de branch hebben geen invloed op andere ontwikkelaars in het team. Dit is natuurlijk een goede zaak, omdat functies die in ontwikkeling zijn instabiliteit kunnen veroorzaken, wat zeer storend zou zijn als al het werk aan de hoofdcoderegel zou plaatsvinden. Maar branches hoeven geen eenzaam bestaan te leiden. Ontwikkelaars kunnen eenvoudig wijzigingen van andere ontwikkelaars ophalen om samen te werken aan functies en ervoor te zorgen dat hun privébranch niet te ver van de hoofdbranch afwijkt.
Branches zijn niet alleen goed voor functiewerk. Branches kunnen het team isoleren tegen belangrijke architectonische veranderingen zoals het bijwerken van frameworks, gemeenschappelijke bibliotheken, enz.
Drie branchingstrategieën voor agile teams
Branchingmodellen verschillen vaak tussen teams en zijn het onderwerp van veel discussies binnen de softwaregemeenschap. Een belangrijk thema is hoeveel werk er in een branch moet blijven voordat deze weer wordt samengevoegd met de main.
Releasebranches
Release-branching verwijst naar het idee dat een release volledig binnen een branch is opgenomen. Dit betekent dat de releasemanager laat in de ontwikkelingscyclus een branch van de main zal maken (bijv. "1.1 ontwikkelingsbranch”). Alle wijzigingen voor de 1.1-release moeten twee keer worden toegepast: eenmaal op de 1.1-branch en vervolgens op de hoofdcoderegel. Werken met twee branches betekent extra werk voor het team en het is gemakkelijk om het samenvoegen van beide branches te vergeten. Release-branches kunnen lastig en moeilijk te beheren zijn omdat veel mensen aan dezelfde branch werken. We hebben allemaal wel eens de last ervaren om veel verschillende wijzigingen op één enkele branch samen te voegen. Als je een release-branch moet maken, maak dan de branch zo dicht mogelijk bij de daadwerkelijke release aan.
Release-branching is een belangrijk onderdeel van het ondersteunen van versiesoftware die op de markt is. Een enkel product kan verschillende releasebranches hebben (bijv. 1.1, 1.2, 2.0) om duurzame ontwikkeling te ondersteunen. Houd er rekening mee dat wijzigingen in eerdere versies (d.w.z. 1.1) mogelijk moeten worden samengevoegd met latere releasebranches (d.w.z. 1.2, 2.0). Bekijk onze webinar hieronder voor meer informatie over het beheren van releasebranches met Git.
Functiebranches
Functiebranches worden vaak gekoppeld aan functievlaggen: 'schakelaars' die een functie in het product in- of uitschakelen. Dat maakt het eenvoudig om code in de main en control te implementeren wanneer de functie is geactiveerd, waardoor het gemakkelijk is om de code in eerste instantie te implementeren ruim voordat de functie wordt blootgesteld aan eindgebruikers.
Een ander voordeel van functievlaggen is dat de code, mits inactief, binnen de build kan blijven terwijl deze in ontwikkeling is. Als er iets misgaat terwijl de functie is ingeschakeld, kan een systeembeheerder de functievlag terugzetten en terugkeren naar een bekende goede staat in plaats van een nieuwe build te moeten implementeren.
Taakbranches
Bij Atlassian richten we ons op een branch-per-taak-workflow. Elke organisatie heeft een natuurlijke manier om werk op te splitsen in individuele taken in een issuetracker, zoals Jira. Issues worden dan het centrale aanspreekpunt van het team voor dat werkonderdeel. Taakbranching, ook wel issuebranching genoemd, verbindt deze issues rechtstreeks met de broncode. Elke issue wordt geïmplementeerd in zijn eigen branch met de issuecode die in de branchnaam is opgenomen. Je kunt gemakkelijk zien welke code welk issue implementeert: je hoeft alleen maar de issuesleutel in de branchnaam te zoeken. Met die mate van transparantie is het eenvoudiger om specifieke veranderingen toe te passen op de main of een al langer actieve, oudere releasebranch.
Omdat agile draait om userstory's, passen taakbranches goed bij agile ontwikkeling. Elke userstory (of bugfix) bestaat binnen een eigen branch, waardoor eenvoudig te zien is welke issues in voortgang zijn en welke er klaar zijn voor release.
Maak nu kennis met het slechte evenbeeld van branching: de samenvoeging
We kennen allemaal de moeite die het kost om meerdere branches in één logische oplossing te integreren. Van oorsprong hebben gecentraliseerde versiebeheersystemen, zoals Subversion, van het samenvoegen een zeer complexe handeling gemaakt. Maar nieuwere versiebeheersystemen zoals Git en Mercurial hanteren een andere benadering voor het bijhouden van bestandsversies die in verschillende branches zitten.
Branches hebben de neiging om kortstondig te zijn, waardoor ze eenvoudig samengevoegd kunnen worden en flexibeler zijn in de codebase. Tussen het vermogen om vaak en automatisch branches samen te voegen als onderdeel van continue integratie (CI) en het feit dat kortstondige branches simpelweg minder veranderingen bevatten, behoort het 'de hel van het samenvoegen' tot het verleden voor teams die Git en Mercurial gebruiken.
Daarom zijn taakbranches zo geweldig!
Valideren, valideren, valideren
Een versiebeheersysteem kan maar tot op zekere hoogte de uitkomst van een samenvoeging beïnvloeden. Geautomatiseerd testen en continue integratie zijn ook van groot belang. De meeste CI-servers kunnen automatisch nieuwe branches testen, waardoor het aantal 'verrassingen' bij de uiteindelijke samenvoeging stroomopwaarts drastisch wordt verminderd en de hoofdcoderegel stabiel blijft.
