Trunk-based development vs GitFlow voor wekelijkse releases

Waarom wekelijkse releases rommelig worden met het verkeerde branching-model

Wekelijks uitbrengen klinkt simpel—tot de week dat je het mist. De build is “bijna klaar” op donderdag, QA vindt problemen laat op vrijdag, en maandag wordt een schoonmaak in plaats van een frisse start.

Een belangrijke oorzaak is je branching-model. Dat bepaalt wanneer veranderingen samenkomen, waar integratie plaatsvindt en hoe snel je herstelt als er iets kapotgaat. Als integratie naar het einde van de week wordt geschoven, betaal je ervoor met mergeconflicten, verrassingsbugs en wankele testomgevingen.

Als de workflow tegen je werkt, voelt het meestal zo:

• Merges duren langer dan het werk dat ze veroorzaakten.
• QA test de verkeerde combinatie van wijzigingen omdat branches uit elkaar drijven.
• Releases worden een onderhandeling in plaats van routine.
• Hotfixes veroorzaken paniek omdat niemand zeker weet wat er nog meer meekomt.
• Mensen verliezen vertrouwen in QA en vragen om uitzonderingen.

Branching bepaalt ook de stabiliteit van QA. Als QA blijft heen en weer springen tussen half-geïntegreerde codepaden, wordt het een bewegend doel. Zelfs sterke testers kunnen geen duidelijke antwoorden geven als het systeem dat ze testen elk paar uur verandert of een late merge stilletjes vervangt wat ze gisteren getest hebben.

Daarom vergelijken teams trunk-based development en GitFlow als ze naar een wekelijkse releaseritme gaan. De relevante vraag is niet welke populair is, maar welke de merge-pijn vermindert, releases voorspelbaar houdt, hotfixes veilig en snel maakt, en QA zinvol houdt.

Stel een klein tot middelgroot team voor, één gedeelde repo, CI op elke push. Misschien ship je een web-app en een API. Of een deel bouwt visueel in een platform zoals AppMaster terwijl je nog steeds gegenereerde code en deploys beheert zoals elk productteam.

Als je huidige proces grote, einde-van-de-week merges creëert, zal je wekelijkse cadence blijven schuiven. Als het kleine, frequente integratie aanmoedigt, worden wekelijkse releases saai (in de beste zin).

Trunk-based development en GitFlow in gewone taal

Beide benaderingen zijn regels voor hoe je branches gebruikt zodat werk van "in progress" naar "released" kan zonder chaos. Het echte verschil is hoeveel langlopende branches je hebt en hoe lang werk gescheiden blijft voordat het anderen ontmoet.

• Trunk-based houdt bijna alles dicht bij main.
• GitFlow houdt aparte banen voor doorlopend werk en release-stabilisatie.

Trunk-based development (in simpele termen)

Trunk-based development behandelt main (de trunk) als het centrum. Mensen werken in kortlevende branches (enkele uren tot een dag of twee), mergen vaak terug en houden main in een releasable staat.

Als iets niet klaar is, houd je het klein genoeg om snel af te krijgen of verberg je het achter een feature flag zodat het veilig kan shippen zonder zichtbaar te zijn.

GitFlow (in simpele termen)

GitFlow gebruikt meestal een langlopende develop branch waar featurewerk eerst naartoe gaat, plus feature-branches van develop. Tegen de release maak je een release/* branch om te stabiliseren en testen. Als productie breekt, maak je een hotfix/* branch (vaak vanaf main) en merge je die terug.

Dit model optimaliseert voor scheiding: doorlopend werk kan op develop doorgaan terwijl de release-branch getest en gepatched wordt.

Veel pijn komt voort uit veelvoorkomende misverstanden:

• Trunk-based behandelen als “geen branches” (er worden nog steeds branches gebruikt; ze zijn kortlevend).
• GitFlow gebruiken maar nooit een echte release-branch maken, waardoor develop een onstabiel staginggebied wordt.
• Feature-branches wekenlang laten leven, wat elk model in merge-problemen verandert.
• "Releasable" verwarren met "alles is af" in plaats van "veilig om te deployen".

Merge friction: wat het echt veroorzaakt

Mergeconflicten komen meestal door twee oorzaken: branches die te lang leven, en meerdere mensen die zonder coördinatie aan dezelfde gebieden werken.

Het grootste praktische verschil tussen trunk-based en GitFlow is hoe lang werk apart blijft voordat het met ander werk samenkomt.

Bij trunk-based development komen veranderingen vaak op de hoofdlijn. Pull requests zijn kleiner, diffs zijn kleiner en conflicten verschijnen eerder terwijl de context nog vers is. Conflicten blijven voorkomen, maar ze zijn meestal makkelijker op te lossen omdat je een paar regels reconcilieert, niet twee weken drift. Het nadeel is discipline: hou builds groen, houd veranderingen incrementeel en behandel main als het product.

Bij GitFlow kan featurewerk langer blijven liggen zonder alledaags andere ontwikkelaars te beïnvloeden. De kosten verschijnen later als grotere merge-events: feature → develop, develop → release/* en release/* → main. Elke merge is een grotere samenkomst van veranderingen, dus conflicten zijn groter en lastiger. Voor wekelijkse releases landen die grote merges vaak precies wanneer het team wil testen.

De code-review-last verschuift ook. Trunk-based betekent meestal meer reviews, maar elk is sneller te begrijpen. GitFlow betekent vaak minder, zwaardere reviews, plus extra reviewtijd tijdens release-merges wanneer iedereen moe is.

Om mergefrictie te verminderen in beide modellen:

• Houd PRs klein en gericht (één doel tegelijk).
• Spreek eigenaarschap af voor risicovolle gebieden (migrations, gedeelde config, core UI).
• Haal dagelijks upstream-veranderingen binnen zodat je niet drijft.
• Als een bestand constant "hot" is, werk er samen aan in plaats van parallel te botsen.

Als conflicten constant voelen, is het meestal een teken dat je te laat integreert, niet dat Git het probleem is.

Release-voorspelbaarheid voor een wekelijkse cadence

Voorspelbaarheid betekent drie dingen: je weet wanneer de release uitgaat, je weet wat erin zit en je weet welke checks moeten slagen voor deploy. Teams missen wekelijkse releases meestal omdat ze scopebeslissingen mixen met last-minute fixes.

Bij trunk-based blijven wekelijkse releases voorspelbaar wanneer main groen blijft. Je merged kleine veranderingen vaak en regelt scope met feature flags in plaats van langlopende branches. Zo blijft de wekelijkse trein rijden, zelfs als een feature niet af is. De code kan landen, maar het gebruikerszichtbare gedrag blijft uit totdat het klaar is.

Quality gates zijn vaak eenvoudiger omdat er één plek is om te valideren:

• Geautomatiseerde tests moeten slagen op main.
• QA test een stabiele kandidaat-build, niet wat er het laatste uur is binnengekomen.
• Rollout- en rollback-stappen zijn opgeschreven.
• Er is een duidelijke release-cutoff tijd (ook al blijven commits landen).

In GitFlow komt voorspelbaarheid doordat de release-branch als een freeze-zone fungeert. Je kiest een cutoff, maakt release/* en staat alleen changes toe die nodig zijn om te shippen. Die grens helpt, maar voegt coördinatie toe omdat fixes meestal op meer dan één plek toegepast moeten worden (release en develop).

Onvoltooide werkzaamheden worden anders behandeld:

• Trunk-based: merge veilige stukken en houd de rest achter flags.
• GitFlow: laat onvoltooid werk in develop en sluit het uit van de release-branch.

Voorbeeld: als verbeteringen aan de checkout half af zijn op woensdag, kan trunk-based de veilige refactors mergen en de nieuwe UI verborgen houden. GitFlow houdt het meestal in develop, shipt zonder het en maakt het af voor de volgende weekly release.

Hotfix-flow: het snelste veilige pad naar productie

Een hotfix is geen normaal werk. Het heeft snelheid, laag risico en een pad nodig dat de wijziging terugbrengt naar waar het team werkt zodat je dezelfde bug niet twee keer fixt.

Begin met één vraag: welke exacte code draait er nu in productie? Als je dat niet binnen seconden kunt beantwoorden, wordt een hotfix giswerk.

Hotfixes met trunk-based development

Hotfixes kunnen eenvoudiger aanvoelen omdat main als bron van waarheid wordt behandeld.

Een veelgebruikt verloop:

• Maak een kortlevende branch van de productiecommit (vaak main).
• Doe de kleinste mogelijke fix (voeg een test toe als je kunt).
• Merge snel terug naar main.
• Deploy vanaf main en tag de release.

Omdat het team vaak naar main integreert, wordt de hotfix natuurlijk onderdeel van de volgende wekelijkse release. Het grootste risico is dat je de regel "main is releasable" schaadt door half-af werk in main te laten zitten. Feature flags helpen, maar houd ze standaard uit en verifieer de hotfix zonder gerelateerde features in te schakelen.

Hotfixes met GitFlow

In GitFlow beginnen hotfixes meestal vanaf main (productie) en moeten vervolgens in develop worden gemerged zodat de fix niet verloren gaat.

Een veilig verloop:

• Branch hotfix/* vanaf de productie-tag op main.
• Fix en release (of vanaf de hotfix-branch of na merge naar main).
• Merge de hotfix naar main en ook naar develop.
• Als er een release/* branch bestaat, merge daar ook naartoe.

De meest voorkomende fout is het vergeten van één van die merges. Een week later keert de bug terug omdat develop de patch nooit kreeg.

Een simpele regel voorkomt dit meestal: een hotfix is niet klaar totdat hij in elke langlopende branch is gemerged die opnieuw zal shippen.

Hoe QA-omgevingen stabiel te houden (zonder het team te blokkeren)

Wekelijks shippen valt uit elkaar wanneer "QA" betekent "wat er nu toevallig deployed is." Noem je omgevingen en geef elke omgeving een taak: dev voor snelle feedback, QA voor teamtesten, staging voor releasechecks, prod voor klanten. Als je niet in één zin het doel van een omgeving kunt uitleggen, zullen mensen hem verkeerd gebruiken.

Regels die bewegende doelen voorkomen

Stabiele QA gaat minder over het branching-model en meer over wat je deployt.

Bij trunk-based werk: deploy geen willekeurige commits naar QA. Deploy een gepinde kandidaat (getagde build, buildnummer of een kortlevende release-candidate branch) die elke keer dezelfde checks passeert. QA krijgt iets stabiels om te testen, terwijl development op main doorgaat.

In GitFlow volgt QA meestal de release-branch. De valkuil is dat je de release-branch blijft wijzigen nadat QA begonnen is. Zodra QA start, behandel de release-branch als een contract: accepteer alleen goedgekeurde fixes en alleen via een duidelijk proces.

Een kleine set regels houdt beide benaderingen voorspelbaar:

• Deploy naar QA alleen vanaf groene builds.
• Pin de gedeployde versie (tag, buildnummer of release-branch head) en kondig die aan.
• Beperk QA-wijzigingen tot bugfixes, geen nieuwe features.
• Reset testdata op schema en documenteer wat gewist wordt.
• Houd configuratie als code (variabelen en templates) om omgevingdrift te verminderen.

Als je team AppMaster gebruikt voor een deel van de build, houd dan hetzelfde principe: regenereer en deploy een specifieke build voor QA, niet een constant veranderende set bewerkingen.

Als meerdere teams QA delen

Eén gedeelde QA-omgeving wordt een bottleneck als twee teams verschillende versies nodig hebben. Als je geen aparte QA-omgevingen kunt veroorloven, voeg een lichtgewicht reserveringsregel toe: één team heeft QA voor een tijdsvenster en de rest gebruikt dev of staging. Feature flags helpen ook omdat onafgewerkt werk gedeployed kan worden zonder zichtbaar te zijn voor testers.

Voorbeeld: Team A valideert de wekelijkse release candidate, dus QA blijft gepind op build 1842 tot sign-off. Team B kan fixes blijven mergen, maar die veranderingen wachten op de volgende kandidaat in plaats van te verschuiven wat QA test tijdens de cyclus.

Stappenplan: kies een workflow die je team elke week kan volgen

Schrijf op wat "wekelijkse shipping" voor jullie betekent. Kies een releasedag en -tijd, bepaal welk risiconiveau acceptabel is (bijv. "geen bekende P1-bugs") en noteer teamgrootte en tijdzones. Dit voorkomt dat branch-discussies in prioriteitsargumenten veranderen.

Kies één basismodel en commit er een maand aan. Meng niet meteen modellen. Mengen voegt meestal regels toe zonder verrassingen te verminderen.

Een simpel wekelijks workflow-voorstel dat je kunt aanpassen:

• Houd branch-lifetimes kort (uren tot 1–2 dagen) en merge minstens dagelijks.
• Voeg veiligheidsrails toe: snelle CI, een korte verplichte review en een kleine set geautomatiseerde tests die echte breukpunten vangen.
• Bepaal hoe je scope controleert: feature flags, een kortlevende release-branch tegen het einde van de week, of tags voor het exacte release-commit.
• Definieer hotfix-stappen: wie mag er een trigger doen, welke checks zijn vereist en hoe de fix terug in de hoofdlijn komt.
• Houd QA stabiel: beslis waar QA op volgt (release-branch of gepinde kandidaat) en verander dat niet halverwege de test tenzij je de testcyclus herstart.

Schrijf het minimale proces op één pagina. Het moet kort genoeg zijn zodat een nieuwe collega het kan volgen zonder meeting. Dit is extra belangrijk als een deel van het team visueel werkt (bijv. in AppMaster) en een deel in code, omdat handoffs falen als regels alleen in iemands hoofd leven.

Voorbeeld: een realistische wekelijkse release in beide modellen

Stel je een productteam van 6 personen voor dat elke vrijdag shipt. Twee QA-testers delen één staging-omgeving, dus als staging onstabiel is, stopt het testen voor iedereen.

Een drukke week met GitFlow

Maandag: drie developers maken features af en openen pull requests naar develop. QA begint met het testen van staging gebouwd vanaf develop.

Woensdag: het team knipt release/1.8 om vrijdags te beschermen. Nieuw werk landt in develop, maar QA focust op de release-build.

Donderdagmiddag: er verschijnt laat een bug. De fix gaat eerst in release/1.8 zodat QA snel kan retesten. Daarna merge iemand die fix terug naar develop, en daar gebeuren vaak fouten.

Een typisch ritme:

• Ma-Di: features mergen naar develop, staging verandert vaak.
• Wo: maak release/1.8, staging schakelt naar release-builds.
• Do: bugfix in release/1.8, daarna merge terug naar develop.
• Vr: merge release/1.8 naar main, tag en deploy.

Dezelfde week met trunk-based development

De week draait om kleine, frequente merges naar main. Features zitten achter flags zodat onafgewerkt werk kan mergen zonder gebruikers te beïnvloeden.

Maandag t/m donderdag: developers mergen dagelijks kleine veranderingen. QA test een gepinde kandidaat-build.

Dinsdag: er verschijnt een productieprobleem. De hotfix is een korte branch vanaf main, wordt meteen teruggemerged na review en vervolgens gepromoveerd naar productie. Omdat main de bron van waarheid is, is er geen extra back-merge stap.

Hoe dan ook, het team heeft duidelijke promotie-regels nodig:

• Staging draait de laatste gepinde candidate-build, niet elke nieuwe commit.
• QA vraagt om een nieuwe candidate wanneer ze klaar zijn, niet automatisch.
• Alleen fixes voor de vrijdag-release mogen de candidate veranderen.
• Alles anders wacht achter flags of blijft buiten de candidate.

Veelgemaakte fouten die churn en onstabiele QA veroorzaken

De meeste teams falen niet omdat ze het "verkeerde" model kozen. Ze falen omdat dagelijkse gewoonten niet bij het model passen, waardoor QA rumoerig wordt en releases willekeurig aanvoelen.

Een veelvoorkomend probleem is branches dagenlang laten liggen omdat "het nog niet klaar is." De code drijft weg van main, conflicten stapelen zich op en QA test een mix van oud en nieuw werk die niemand kan reproduceren.

Een andere fout is GitFlow gebruiken zonder echte freeze. Een release-branch hoort te stabiliseren, maar teams blijven "nog één ding" erin stoppen. Dat maakt de release-branch een tweede mainline en niemand weet waarvoor QA tekent.

QA wordt ook onstabiel wanneer het als een dump-omgeving voor half-af builds wordt gebruikt. Als elke commit naar QA gaat zonder regels, verspillen testers tijd aan een bewegend doel in plaats van een release valideren.

De fouten die de meeste churn veroorzaken:

• Langlevende feature-branches die laat mergen en ongerelateerd werk breken.
• Release-branches die nog steeds nieuwe features accepteren.
• Geen duidelijke promotie-route, zodat de build die QA test niet de build is die shipt.
• Hotfixes gehaast gedaan en daarna nergens overal teruggemerged.
• Omgevingen zonder eigenaar, zonder doel en zonder resetplan.

Houd een set regels die iedereen kan herhalen:

• QA test alleen een gepinde kandidaat.
• Je promoot hetzelfde artifact van QA naar productie.
• Elke omgeving heeft een eigenaar en een reset-cadans.
• Hotfixes vloeien dezelfde dag terug naar de hoofdlijn.

Snelle checklist voor wekelijks shippend zonder verrassingen

Wekelijks shippen werkt als je team een paar saaie vragen met vertrouwen kan beantwoorden. Als je op twee of meer vragen "nee" antwoordt, verwacht late fixes en QA-whiplash.

• Is er één branch die je vandaag veilig kunt deployen? Hij moet builden, smoke-tests passeren en geen half-gekoppelde veranderingen bevatten.
• Blijven pull requests klein en landen binnen een dag of twee? Langlevende PRs betekenen meestal verouderde feedback en grotere conflicten.
• Test QA een vaste build, geen bewegend doel? QA moet een specifiek buildnummer of release candidate valideren.
• Kun je onafgewerkt werk buiten de release houden zonder drama? Feature flags, config-toggles of een duidelijke scope-cut regel.
• Kan iemand een hotfix en rollback uitvoeren zonder te gokken? Een korte runbook verslaat tribale kennis.

Als je één meetbaar doel wilt: pin QA aan een release candidate en houd die kandidaat onveranderd behalve voor bewuste fixes.

Volgende stappen: kies één verandering om volgende week te proberen

Als je team vastzit in een debat over trunk-based vs GitFlow, herontwerp niet meteen alles. Kies het ene probleem dat de meeste tijd kost en voer een klein experiment uit voor de volgende release.

Als mergeconflicten het grootste pijnpunt zijn, verkort dan branch-lifetimes onmiddellijk. Streef ernaar werk dagelijks (of om de dag) te landen en gebruik feature flags waar nodig.

Als QA-instabiliteit het grootste probleem is, begin met het pinnen van wat QA test en definieer een simpele promotiestap.

Een lichtgewicht pilot:

• Kies één repo en één team.
• Stel een tak-leeftijdslimiet in (bijv. geen branch ouder dan 2 dagen).
• Pin QA aan één build en verander die alleen via expliciete promotie.
• Volg drie cijfers: tijd tot merge-resolutie, QA rework-uren en hotfix time-to-production.
• Evalueer na 2–4 weken en pas aan.

Als je release-druk wilt verminderen voor interne tools of klantportalen, kan een no-code platform zoals AppMaster (appmaster.io) ook helpen door productieklare backend, web- en native mobiele apps te genereren vanuit visueel ontwerp. Het profiteert nog steeds van dezelfde gewoonten: kleine veranderingen, gepinde QA-candidates en een duidelijke promotieroute.