Efficiënter ontwikkelen met feature branching

‍

Applicaties ontwikkelen kan een complexe bezigheid zijn. Werken met versiebeheer is geen automatische garantie voor een soepel ontwikkelproces. Wel is er een manier waarbij het makkelijker kan, namelijk feature branching. Deze werkwijze maakt gebruik van verschillende ‘branches’ (takken) om overzicht en structuur binnen het ontwikkelproces te creëren. Het resultaat: je kunt een stuk efficiënter werken.

Feature en development branches

Een feature is een nieuw onderdeel (functionaliteit) van de applicatie. Dit nieuwe onderdeel vereist eigen testen en bijbehorende afhankelijkheden. Bij het ontwikkelen van een splinternieuw onderdeel is het slim om vanuit een aparte branch te werken. Dit is het basisidee achter feature branching; bij het ontwikkelen van een bepaalde functionaliteit reserveer je een aparte tak (branch) van de totale repository (opslagplek) voor het werken aan die specifieke feature. Die werkwijze wordt een branch-per-issue-workflow genoemd.

Branch-per-issue-workflow

Als je kiest voor een branch-per-issue-workflow wordt iedere codewijziging of elk onderdeel van de toepassing ondergebracht in een aparte tak (branch). De master branch is de versie die in productie staat, terwijl de develop branch de ruggengraat van de applicatie vormt. De develop branch is dus het zenuwcentrum van de ontwikkelomgeving. Ontwikkelaars kunnen op basis van de productversie een bugfix maken (bugfix branch). Deze moet dan weer naar de develop branch gebracht worden om de ontwikkel- en productieomgeving goed op elkaar afgestemd te houden.

Maar ontwikkelaars kunnen ook aanpassingen doorvoeren, functionaliteiten toevoegen en tests uitvoeren binnen hun eigen development branch zonder dat die wijzigingen direct doorvloeien naar andere takken van de applicatie. Elke ontwikkelaar heeft dus de vrijheid om te werken aan en te experimenteren binnen zijn eigen tak (code, test, repeat, deploy). Hij kan dus ook zelf bepalen wanneer hij een bepaalde functionaliteit gereed acht voor release en die feature daadwerkelijk live wil zetten. Handig als je nog twijfels hebt over een bepaald onderdeel en dit niet gelijk wilt toevoegen aan de huidige release. Andersom kun je er juist ook voor kiezen om naar tevredenheid geteste functionaliteiten gelijk door te zetten naar de develop branch, zodat de andere ontwikkelaars hier gelijk verder mee kunnen.

Branches samenvoegen kan gevaarlijk zijn

Er komt natuurlijk een moment waarop de in aparte branches ontwikkelde functionaliteiten samengevoegd moeten worden. Dit gaat doorgaans gemakkelijk als een ontwikkelaar alle mainline-veranderingen ook al binnen zijn eigen werktak heeft doorgevoerd en vice versa. Het wordt echter ‘trickier’ als twee of meer ontwikkelaars het werk moeten gaan samenvoegen dat ze hebben uitgevoerd binnen hun eigen branches. Als het gaat om twee op zichzelf staande onderdelen van de code is die fusie meestal niet al te problematisch.

Maar het kan ook zo zijn dat bepaalde onderdelen uit verschillende branches binnen het totaalplaatje met elkaar interacteren. In zo’n geval kan er een hoofdpijndossier ontstaan als de volgende twee zaken samenkomen zonder dat hierover goede afspraken zijn gemaakt: het samenvoegen van broncodes en het oplossen van problemen die ontstaan als meerdere ontwikkelaars tegelijkertijd dezelfde bestanden bewerken.

De oplossingen: branches beheren en Continuous Integration (CI)

Branches beheren

Gelukkig zijn er wel manieren om de bovengenoemde problemen te omzeilen. De mogelijkheden en versatiliteit van de feature branch bieden bijvoorbeeld uitkomst. Maak een aparte feature branch en een development branch aan en voeg die twee pas samen als ze allebei zijn afgerond en getest. Test de feature branch eerst los. Onbekende fouten kun je vervolgens voorkomen door alle nieuwe code van de development branch in jouw eigen feature branch toe te voegen. Werkt dit soepel en foutloos? Dan kun je jouw feature branch met een gerust hart aan de development branch toevoegen.

Gitflow biedt ook oplossingen om niet te verdwalen in het woud van versiebeheer als je codes verandert of repareert.

• Werken met een masterbranch en development branch. De master geeft aan welke onderdelen live staan, de development branch welke nog in ontwikkeling zijn.
• Release branches aanmaken. Het is met Gitflow mogelijk om vanuit de development branch elke keer een release branche aan te maken als je een nieuwe versie van je werk live wilt zetten. De afzonderlijke release branches kun je vervolgens toevoegen aan je master branch. Die slaat alle info op en maakt aan de hand van notificaties een overzicht van de doorgevoerde aanpassingen.

Continuous Integration

In het geval van Continuous Integration vinden er gedurende het hele ontwikkeltraject op veel frequentere basis samenvoegingen plaats tussen functionaliteiten die in afzonderlijke branches staan. Het voordeel hiervan is dat het aantal grote, potentieel problematische samenvoegingen afneemt. Updates worden namelijk op regelmatige basis en met korte intervals toegevoegd aan de mainline.

Daarnaast fungeert Continuous Integration ook als een prima communicatietool. Ontwikkelaars kunnen tussentijds met elkaar overleggen over aan te brengen veranderingen en mogelijke knelpunten. Dit maakt troubleshooting een stuk gemakkelijker dan wanneer iedereen in zijn eigen bubbel blijft en er pas in een later stadium grote samenvoegingen plaatsvinden.

De voordelen van feature branching

Feature branching brengt structuur aan in het ontwikkelproces en heeft daarom een aantal belangrijke voordelen.

• Meerdere ontwikkelaars kunnen tegelijkertijd aan meerdere functionaliteiten werken, zonder dat ze in elkaars vaarwater komen.
• Het werken met verschillende branches creëert een duidelijke geschiedenis die precies laat zien wanneer iets geprogrammeerd en online gezet is. Snelle reparaties gaan met deze werkwijze bovendien niet verloren.
• Feature branching geeft je de mogelijkheid om updates vaker en gemakkelijker online te zetten.
• Ontwikkelaars kunnen hun eigen werktempo aanhouden. Dit leidt tot een betere en prettigere workflow.
• Ontwikkelteams hebben meer vrijheid om het moment te kiezen waarop een bepaalde functionaliteit wordt ingebracht.