Idee voor het combineren van changelogs en feature branches

← Nieuws
15 september 2021

Bij West IT zijn we gedreven op zoek te gaan naar oplossingen om het ontwikkelen van software te vereenvoudigen. Waar het kan werken we volgens best practices, maar soms levert het combineren daarvan juist nieuwe problemen op. Maarten van Schouwen schrijft in deze blog over zijn ervaring met het bijhouden van een changelog terwijl er ook gewerkt wordt met feature branches.

Best practices

Bij alle projecten waaraan ik werkte gebruikte ik de volgende twee best practices: ● Het bijhouden van een changelog: een overzicht van de nieuwe functionaliteit die in elke versie van de software zit. ● Git Feature Branch Workflow: met een team van vijf software-ontwikkelaars gebruiken we deze workflow zodat we elkaar niet in de weg zitten als we aan dezelfde bestanden werken. Elke feature waaraan gewerkt wordt heeft hierbij een eigen "branch" (een vertakking in het versiebeheersysteem oftewel Git). Je zou het kunnen zien als een privékopie van alle bestanden. Als het werk aan een feature is afgerond, voegt Git de gewijzigde bestanden weer samen met de rest. Git noemt dat “mergen”. Dat gaat automatisch en het gaat meestal goed, maar het is mogelijk dat er conflicten optreden. Die moeten dan handmatig worden opgelost.

Problemen bij combinatie van best practices

Op zich zijn bovengenoemde best practices duidelijke en eenvoudige werkwijzen, maar als ze worden gecombineerd, ontstaat er een probleem. Bij het werk op een feature branch wordt gewoonlijk direct een beschrijving van de nieuwe functionaliteit toegevoegd aan de changelog. Die changelog wordt bijgehouden in één bestand. Dat zorgt regelmatig voor merge conflicten bij het afronden van een feature.

Het probleem komt doordat elke ontwikkelaar de nieuwe beschrijving op dezelfde plek in het bestand toevoegt. De best practice schrijft namelijk voor dat de nieuwe versie bovenaan de lijst beschreven moet worden. En als twee mensen op één regel een verschillende tekst willen, dan kan Git dit niet automatisch kan oplossen.

Zelfs als twee ontwikkelaars ieder op hun eigen feature branch aan een totaal onafhankelijk deel van het systeem werken, stuurt de changelog best practice min of meer aan op een merge conflict. Zo'n conflict in de changelog is eenvoudig op te lossen, maar geeft onnodige ergernis. Het lijkt ook altijd op te treden op een moment dat het niet uitkomt, zoals bij het afronden van een feature of bij het voorbereiden van een nieuwe versie.

Vermijden van conflicten als oplossing

Omdat het probleem zit bij het gebruik van één enkel bestand, ben ik een oplossing gaan zoeken bij het gebruiken van meerdere bestanden. Als we elke nieuwe beschrijving in een nieuw bestand zetten, vermijden we merge conflicten. Hierna kunnen we die losse bestanden combineren tot de complete changelog.

Het gaat om veel gebruikte best practices en dus zochten we naar vergelijkbare situaties bij andere ontwikkelteams om te kijken of deze er ook tegenaan lopen. En inderdaad kwam bij een zoektocht op internet het idee om met meerdere bestanden te werken een aantal keer voor.

Nadeel extra handeling bij oplossingen

Maar er zit ook een nadeel aan de gevonden oplossingen, er is namelijk een extra handeling nodig op het moment dat het team een nieuwe versie van de software wil maken. Handmatig moet men beoordelen welke nieuwe, losse bestanden gecombineerd moeten worden tot een sectie in de changelog voor de nieuwe versie. Voor het uiteindelijke samenvoegen van die bestanden zijn er wel tools ontwikkeld.

Volledig automatisch

In theorie is het mogelijk om ook die laatste stap automatisch uit te laten voeren. In het versiebeheersysteem is namelijk terug te vinden welke versies er bestonden op het moment dat een bestand met de beschrijving van een feature is toegevoegd. Daarmee is af te leiden bij welke versie elk bestand in de changelog hoort.

Conclusie en vervolg

Als dit alles automatisch kan, zijn er geen conflicten meer bij het werken met de changelog en zijn er bij het maken van een nieuwe versie minder handmatige acties nodig. De volgende stap is om dit idee uit te werken tot een kant-en-klare oplossing.

Meer weten? Lees meer op de volgende pagina’s: