# Wat is trunk-based development? De strategie van elite teams URL: https://codebasechat.com/nl/journal/wat-is-trunk-based-development Type: blog Locale: nl Published: 2026-09-22 Updated: 2026-09-22 --- > Trunk-based development is een branchingstrategie waarbij elke ontwikkelaar dagelijks naar main mergt. Leer hoe dit riskicobeheersing en deployfrequentie beïnvloedt. Wat is trunk-based development? Dit is een branchingstrategie waarbij elke ontwikkelaar minstens eenmaal per dag naar een centrale branch mergt, meestal `main` of `trunk` genaamd. Er zijn geen langdurige feature branches. Code bevindt zich te allen tijde in een productieklaare staat. Als een feature nog niet klaar is, verbergt een feature flag het voor gebruikers in plaats van een branch dat van het team isoleert. Dat is de korte versie. De langere versie gaat in op waarom jouw huidige workflow mogelijk meer risico genereert dan je beseft. ## Waarom langdurige branches een risico worden De meeste teams leren versiebeheer via feature branches: één branch per ticket, gemerged na review. Het voelt georganiseerd. Wanneer een branch langer dan 24 uur bestaat, is elke commit die je collega's doen op main een toekomstige conflict die je nog niet hebt gezien. Bij een team van acht engineers die elk een twee weken durende branch hebben, voer je niet één integratie uit. Je beheert acht parallelle werelden die elke dag een beetje meer uiteenlopen. Merge day is geen taak. Het is een onderhandeling. Het DORA-onderzoek, de grootste longitudinale studie naar softwaredelivery-prestaties uitgevoerd onder duizenden teams, trekt hier een harde lijn: branches die langer dan 24 uur bestaan, zijn een voorspellend teken voor lagere deployfrequentie en hogere foutpercentages bij wijzigingen. Elite-teams integreren meerdere keren per dag. Andere teams mergen wanneer de feature "klaar" is, wat vaak betekent: nooit schoon. De verborgen kostprijs is niet het merge-conflict zelf. Het is de context-switching die vereist is om dit drie weken nadat de code was geschreven op te lossen. Niemand herinnert zich meer wat de bedoeling was. ## Hoe trunk-based development in de praktijk werkt De mechanica is eenvoudig. Je pulled main. Je maakt een kleine, coherente wijziging. Je voert de testsuite uit. Je pushed naar main. Dit alles gebeurt voordat je naar lunch gaat. Voor een individuele bijdrager in een kleine repository is dit al hoe het werkt. Voor een team van twintig in een 300K-LOC monorepo vereist het drie praktijken die samenwerken: **Kortdurende branches (optioneel maar gebruikelijk)**: Sommige teams staan branches toe tot twee dagen voordat ze een merge afdwingen. Dit behoud de code review-cultuur zonder multi-week divergentie te creëren. De branch is een review-voertuig, geen isolatiemechanisme. **Continue integratie bij elke push**: Elke commit naar main triggert een volledige build en testsuite. Als het breekt, gebeurt dat in minuten, niet nadat een twee weken durende feature branch vrijdagavond om 16:00 uur is gemerged. **Feature flags voor onvolledig werk**: Onafgemaakte features worden in productie uitgeleverd achter een flag. Gebruikers zien niets. Het team integreert alles. Dit is het onderdeel dat de meeste teams overslaan, wat is waarom hun eerste TBD-experiment mislukt. Geen van deze praktijken is exclusief voor trunk-based development. Het verschil is dat TBD alle drie verplicht maakt in plaats van optioneel. ## Feature flags: het mechanisme dat TBD laat werken ![Developer hands at a laptop keyboard with a feature flag dashboard visible on screen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/283060-inline1.webp) Een feature flag is een voorwaarde in je code die bij runtime wordt geëvalueerd. Wanneer een flag uit staat, voert het nieuwe codepad zich niet uit. Wanneer het aan staat, voor een specifieke gebruiker, een percentage van het verkeer, of de hele gebruikersbasis, doet het dat wel. Dit klinkt triviaal. De implicatie niet: je kunt deployment scheiden van release. Code wordt continu naar productie geleverd. Features gaan live wanneer ze klaar zijn, of helemaal niet als de rollout misgaat en je het in tien seconden moet stoppen in plaats van drie weken commits terug te draaien. De minimale leefbare setup vereist drie dingen: een manier om flags te definiëren, een manier om ze bij runtime te evalueren, en een manier om ze te wijzigen zonder opnieuw te deployen. Een platte JSON-config werkt voor een team van drie. Een dedicated feature management service verdient zijn complexiteit ergens rond tien engineers of wanneer flags targeting rules nodig hebben zoals "ingeschakeld voor gebruikers in de bètagroep in Duitsland." Één ding om bij te houden: flag debt. Flags die nooit worden schoongemaakt nadat de feature is uitgerold, worden voorwaardelijke spaghetti. Een team dat TBD correct doet, stelt elke flag buiten werking binnen één sprint nadat de feature volledig is uitgerold. Behandel flags als tijdelijke ondersteuning, geen permanente configuratie. ## TBD versus Gitflow: een directe vergelijking voor 2026 Gitflow was ontworpen in 2010 voor in dozen verpakte software die op kwartaalbasis werd geleverd. Het modelleert releases als langdurige branches. Voor teams die elke dag of elk uur deployen, is dat model niet meer van toepassing. Hier is hoe de vergelijking eruit ziet voor een team dat CI/CD draait: **Branch-levensduur**: Gitflow loopt dagen tot weken. TBD loopt uren tot maximaal 1-2 dagen. **Merge conflicts**: Gitflow produceert frequent, high-severity conflicten. TBD produceert zeldzaam, low-severity omdat integratiegaten uren zijn, geen weken. **Deploy frequency**: Gitflow koppelt deployment aan een release branch. TBD ontkoppelt deployment van release geheel. **Rollback mechanism**: Gitflow rolt terug door een branch merge terug te draaien. TBD rolt terug door een feature flag uit te zetten. **Onboarding complexity**: Gitflow vereist begrijpen van develop/main/hotfix conventies. TBD heeft één branch: main. **Required CI investment**: Gitflow is laag (branches absorberen het risico). TBD is hoog (main moet te allen tijde groen blijven). Gitflow is niet in elke context verkeerd. Als je een mobiele app naar een App Store uitgeeft en niet in minuten hotfixes kunt pushen, maakt een release branch model zin. Als je een SaaS draait waar je deployments controleert, is de extra branchingstructuur overhead die coördinatiekosten toevoegt zonder veiligheid toe te voegen. ## Wat DORA-metrieken zeggen over branchingstrategieën ![Two engineers doing pair programming and code review at a shared screen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/7ec1d3-inline2.webp) Het [DORA State of DevOps-onderzoek](https://dora.dev/research/) volgt softwaredelivery-prestaties sinds 2014. Twee bevindingen uit de gegevens zijn hier direct relevant. Ten eerste is trunk-based development een van de 24 mogelijkheden die softwaredelivery-prestaties voorspellen in het DORA-model. Het valt onder het cluster "continuous delivery", wat betekent dat DORA het als infrastructuurpraktijk behandelt, niet teamvoorkeur. Ten tweede deployen elite-teams meerdere keren per dag. Onderperformers deployen eenmaal per week of eenmaal per maand. Langdurige branches en onfrequente integratie verschijnen aan de tragere kant van die verdeling over meerdere jaren gegevens. Wat het onderzoek niet beweert: dat TBD eliteprestaties veroorzaakt. Teams die TBD succesvol toepassen, hebben meestal al geautomatiseerde tests, een werkende CI-pipeline en een gewoonte van kleine commits. Trunk-based development maakt die gaten onmiddellijk zichtbaar als ze ontbreken. Een team zonder CI en 40% testflakiness zal niet baat hebben bij TBD. Ze zullen main gewoon vaker breken. ## Waar trunk-based development niet meer zinvol is Drie scenario's waarin TBD meer problemen creëert dan het oplost: **Sterk gereglementeerde omgevingen met verplichte pre-release goedkeuringsgates**: Als elke release compliancegoedkeuring nodig heeft voordat deze kan worden uitgeleverd, wordt continue deployment naar productie toch geblokkeerd. Het branchingmodel wordt secundair. Je zult wijzigingen samenvoegen, ongeacht de branchingstrategie. **Onvoldoende testsuite**: TBD vereist een snelle, betrouwbare CI-pipeline. Als builds 45 minuten duren en 20% flakiness hebben, zullen ontwikkelaars commits bundeleren om op wachten te voorkomen. Dat verslaat het model. De beperking is de testinfrastructuur, niet de branchingconventie. **Zeer grote teams met inconsistente code-eigendom**: Bij teams van 50+ waar elk squad een afzonderlijke service eigenaar is, werkt TBD goed op serviceniveau. Het toepassen op een gedeelde monorepo waar iedereen alles aanraakt, vereist strikte linting-conventies en CI-eigendomsregels om main schoon te houden. In alle drie gevallen is de oplossing geen andere branchingstrategie. De oplossing is het onderliggende infrastructuurprobleem. TBD maakt dat probleem gewoon sneller zichtbaar. ## Hoe migreren zonder deliveries te stoppen De migratie waar de meeste teams het fout doen: ze melden TBD aan, verwijderen de feature branch conventie, en zien main breken in de eerste week. Een veiliger pad: - **Behoud bestaande branches, voeg een levensduurregel toe**: Geen branch leeft langer dan 3 dagen. Dit dwingt de druk van frequente integratie af zonder het licht uit te doen. - **Eerst je CI instrueren**: Voordat merging snel gaat, moet merging veilig zijn. Zorg ervoor dat de testsuite groen is, onder de 15 minuten loopt, en de main branch blokkeert bij mislukking. - **Kies één feature om met een flag te gaten**: Bouw de flag management spier op voordat je het voor elke onafgemaakte feature nodig hebt. - **Verkort branch lifetime week voor week**: Van 3 dagen naar 2 dagen naar 1 dag over zes weken. Volg merge conflict frequentie als leading indicator. Wanneer het daalt, werkt het model. - **Verwijder de oude conventie alleen wanneer de nieuwe werkt**: Gitflow-conventies blijven gelden voor alles buiten de pilot. Beide modellen 6-8 weken tegelijk draaien is prima. ## De gewoonte die voorspelt of TBD vast zal blijven ![Engineer monitoring CI/CD pipeline dashboards with green deployment status indicators](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/0e3fc0-inline3.webp) Trunk-based development faalt niet omdat teams niet naar main kunnen mergen. Het faalt omdat ontwikkelaars niet de gewoonte hebben werk klein genoeg in te kader om in een dag uit te leveren. De onderliggende verschuiving is niet technisch. Het is hoe werk in planning wordt gedefinieerd. Een story die zegt "implementeer de nieuwe payment flow" is een twee weken durende branch die op komst is. Een story die zegt "voeg de route handler toe en return 501 achter flag `payment-v2`" is een half dag commit. Dit vereist PM-betrokkenheid en backlog-hygiene die de meeste teams niet hebben opgebouwd. De branchingstrategie wijziging neemt een dag aan te kondigen. De scoping discipline neemt zes maanden om op te bouwen. De teams die bij TBD blijven, zijn degenen die drie dingen investeerden voordat ze overschakelden: een sub-15-minuten CI-pipeline, een werkende feature flag service, en sprintuitzendingen die verhalen opleveren klein genoeg om in een dag af te sluiten. Zonder die drie is de branchingconventie de verkeerde hefboom. ## Tools die teams helpen TBD-workflows uit te voeren Het draaien van trunk-based development op teamniveau betekent meer synchrone afstemming: snelle standups om integratiedrift op te vangen, gedocumenteerde conventies voor flags en CI-regels, en aanroepen voor pair-review op kritieke paden. ## FAQ ### Wat is het verschil tussen trunk-based development en Gitflow? Gitflow gebruikt langdurige branches voor releases. TBD mergt alles dagelijks naar main en gebruikt feature flags voor onvolledig werk. TBD leidt tot hogere deployfrequentie en lagere merge-conflicten. ### Waarom zijn langdurige feature branches risicovol? Branches die langer dan 24 uur bestaan creëren divergentie. Elk team commit wordt een potentieel conflict. DORA-onderzoek toont aan dat dit leidt tot lagere prestaties. ### Hoe zorg je ervoor dat onvolledig werk niet in productie gaat? Je gebruikt feature flags. Nieuwe code wordt in productie gedeployed maar verstopt achter een conditie. Dit scheidt deployment van release. ### Kan elke team trunk-based development gebruiken? Niet in alle contexten. Sterk gereglementeerde omgevingen met goedkeuringsgates, onvoldoende testsuite, of onvoldoende CI-investering maken TBD moeilijk. ### Hoe migreer je naar trunk-based development? Geleidelijk: start met een 3-dagen branch-lifetime regel, zorg voor snelle CI, implementeer feature flags, en verkort het gradually. Pas de oude conventie toe buiten de pilot. ### Wat betekent DORA-onderzoek voor mijn team? DORA toont aan dat trunk-based development een voorspeller is van elite performance. Teams die dit implementeren ervaren meer deployments per dag en lagere foutpercentages.