Trunk-based development: waarom één branch, en welke pipeline als AI-agents committen

Trunk-based development past in één zin: iedereen integreert zijn werk in één enkele branch, meerdere keren per dag. Wat het vol te houden maakt, past in een tweede: een snelle deployment pipeline waarvan het oordeel definitief is.

AI-agents die code schrijven en committen, veranderen niets aan die regels. Ze maken ze juist noodzakelijker.

Trunk-based development of feature branches: wat er echt verandert

De trunk is de hoofdbranch, ook wel main of mainline genoemd. Bij trunk-based development merget elke developer zijn werk daar minstens één keer per dag in, soms vaker. Maakt hij branches aan, dan bestaan die meestal hooguit een paar uur, en heeft het team er nooit meer dan drie tegelijk actief. Een feature branch bevat daarentegen dagen of weken werk (DORA, “Trunk-based development”).

MinimumCD maakt er een minimumvoorwaarde voor continuous integration van: werk wordt minstens één keer per dag in de trunk geïntegreerd.

Farley gaat verder. Zijn ideale branchingstrategie bestaat uit twee woorden: “Don’t Branch!” Als er al branches zijn, moeten ze piepklein, weinig in aantal en kortlopend zijn, en minstens één keer per dag gemerged worden. Als een team goed werkt, merget het elke 10 à 15 minuten (Continuous Delivery Pipelines, 2021, p. 44).

Het verschil zit dus niet in de tool. Het zit in hoe lang een wijziging los van de rest blijft bestaan.

Waarom langlopende branches meer kosten dan het lijkt

Een langlopende branch stelt de integratie uit. Zolang hij bestaat, gaat de trunk zonder hem verder, en hij zonder de trunk. Ze groeien uit elkaar. Op de dag van de merge moet alles wat aan beide kanten veranderd is, weer bij elkaar gebracht worden.

Humble en Farley beschrijven de belofte en wat ervan terechtkomt. De belofte: sneller gaan door grote wijzigingen op een branch te doen en alles aan het eind terug te mergen. In de praktijk wordt juist dat terugmergen het moeilijke deel, en hoe groter de wijziging, hoe lastiger de laatste merge. Ze vatten het samen in één zin: hoe overtuigender de reden om een branch aan te maken lijkt, hoe minder je het zou moeten doen (Continuous Delivery, 2010, p. 349). Ze merken ook op dat een applicatie waarvan het werk op branches gebeurt, niet continu geïntegreerd wordt (p. 347).

DORA koppelt trunk-based development aan betere prestaties in softwarelevering en beheer, op basis van zijn gegevens uit 2016 en 2017. Hetzelfde programma raadt aan geen code freeze en geen integratiefase te hebben (“Trunk-based development”).

Een kortlopende branch is ook een kleine wijziging.

De deployment pipeline: een commit stage onder de vijf minuten, één artifact

Meerdere keren per dag integreren houdt alleen stand als elke integratie snel wordt gecontroleerd. Dat is de taak van de deployment pipeline.

De commit stage compileert de code, draait de snelle tests en geeft de developer binnen 5 minuten zijn oordeel (Continuous Delivery Pipelines, p. 52 en 121). Slaagt hij, dan levert hij de release candidate op: precies de eenheid die in productie terechtkomt, als hij zo ver komt (p. 58).

Die candidate wordt maar één keer gebouwd. Humble en Farley leggen uit waarom: wie bij elke stage opnieuw compileert, loopt het risico iets anders in productie te zetten dan wat getest is (Continuous Delivery, p. 113 en 114).

De candidate wordt opgeslagen in een artifact repository. Farley noemt die de “version of truth”: wat erin staat, zijn precies de bits en bytes die we in productie willen deployen. De configuratie die bij elke omgeving hoort, staat daar los van, en er wordt geen versie gebouwd voor een specifieke omgeving (Continuous Delivery Pipelines, p. 60).

De acceptance stage neemt die candidate en doorloopt altijd dezelfde vier stappen: de omgeving configureren, de candidate deployen, controleren dat hij opstart, de acceptatietests draaien (p. 65). Handmatige tests zijn verkennend. Ze worden alleen uitgevoerd op candidates die de acceptatie al doorstaan hebben, en dienen niet om op regressie te testen (p. 73 en 74).

MinimumCD vat deze regels samen. De pipeline is de enige manier om naar welke omgeving dan ook te deployen. Het artifact is onveranderlijk: na de commit past geen mens er nog iets aan. De pipeline beslist of een wijziging naar productie mag, en zijn oordeel is definitief.

Dit is het principe, als pseudoconfiguratie, zonder de syntaxis van een tool:

# Pseudoconfiguratie geschreven voor dit artikel: het principe, geen tool.
pipeline:
  trigger: elke commit op de trunk

  commit stage:
    beoogde duur: minder dan 5 minuten
    doen:
      - compileren
      - de snelle tests draaien
      - de candidate bouwen, één keer
      - de candidate opslaan in de artifact repository
    bij falen: de lijn stilleggen

  acceptance stage:
    exclusief: de hele stage, van de eerste tot de laatste stap
    candidate: de meest recente die de commit stage heeft doorstaan
    doen:
      - de omgeving configureren
      - de candidate deployen
      - controleren dat hij reageert
      - de acceptatietests draaien
      - de omgeving stoppen
    bij falen: de lijn stilleggen

  productie:
    candidate: degene die de acceptatie heeft doorstaan
    doorzetten: besloten door een persoon (Continuous Delivery)
      of automatisch (Continuous Deployment)

Rode pipeline: alles ligt stil, herstellen of terugdraaien

Een rode pipeline betekent één ding: de trunk is niet meer klaar voor productie. Voor Farley is dat de prioriteit van het team: de weg naar productie vrijhouden (Continuous Delivery Pipelines, p. 57). MinimumCD zegt het nog directer: als de hoofdpipeline rood is, stopt al het werk aan functionaliteit.

Humble en Farley noemen dat de lijn stilleggen (“stop the line”): als een deel van de pipeline faalt, stop je (Continuous Delivery, p. 119).

Daarna zijn er maar twee opties. Binnen een minuut of tien herstellen, of de wijziging terugdraaien (Continuous Delivery Pipelines, p. 56). En als degene die de wijziging maakte niet aanwezig is, draait het team die voor hem terug (p. 57).

git switch main && git pull
git revert --no-edit <boosdoener-commit>
git push

Het terugdraaien is zelf ook een commit. Die gaat door de pipeline zoals alle andere, en de geschiedenis houdt bij wat er gebeurd is.

Als AI-agents committen: meer commits, dezelfde regels

Het DORA-rapport van 2024 heeft iets gemeten wat de auteurs niet verwachtten. Als de adoptie van AI met 25 % stijgt, daalt de leveringsdoorvoer met naar schatting 1,5 % en de stabiliteit met naar schatting 7,2 % (Accelerate State of DevOps 2024, p. 39 en 40). Het zijn schattingen op basis van een enquête: een correlatie, geen bewijs van een oorzakelijk verband.

De auteurs opperen een hypothese. Met AI kun je in dezelfde tijd veel meer code produceren. Het is dus mogelijk, en volgens hen zelfs waarschijnlijk, dat wijzigingen groter worden. En hun gegevens laten al jaren zien dat grote wijzigingen trager zijn en vaker instabiliteit veroorzaken (p. 40).

Als de hypothese klopt, is het antwoord geen nieuwe tool. Het is de discipline van kleine batches, toegepast op agents net als op mensen. DORA beschrijft werken in kleine batches trouwens als een vangnet bij de adoptie van AI (“Working in small batches”).

MinimumCD leidt er concrete regels voor agents uit af (“Agentic CD”):

• een wijziging die een agent schrijft, moet minstens het kwaliteitsniveau halen dat van een door een mens geschreven wijziging wordt geëist;
• ze wordt gedeployed via dezelfde pipeline als elke andere wijziging;
• een agent die een wijziging schrijft, mag die niet naar productie kunnen promoten;
• zolang de pipeline rood is, maken agents alleen wijzigingen die hem weer groen krijgen.

Een agent heeft dus niet meer rechten dan een developer. De pipeline blijft de enige weg naar productie.

Blijft de code review over. Bryan Finster, maintainer van MinimumCD, pleit in “AI broke your code review, here’s how…” ervoor menselijk oordeel te bewaren voor wat het echt nodig heeft: het gedrag dat het team vóór de code samen vastlegt, de scenario’s die acceptatietests worden, de kennis die eigen is aan het team, en compliance. In een LinkedIn-bericht van 24 september 2026 beschrijft hij een van zijn beste teams. Geen enkele code review hield de levering tegen: “Our pipelines reviewed the code” (onze pipelines deden de code review).

Wat AI zelfstandig goed doet, en wat erbij nodig is voor een applicatie die in productie overeind blijft, leggen we uit in ons artikel over een app bouwen met AI.

Een gedeelde acceptatieomgeving: één candidate tegelijk, de nieuwste eerst

Meer commits betekent meer candidates. Wat gebeurt er als de acceptance stage bezet is en er nieuwe candidates binnenkomen?

Humble en Farley antwoorden met een voorbeeld (Continuous Delivery, p. 118 en 119, figuur 5.6). De acceptatietests draaien op candidate 1. Intussen komen er andere wijzigingen binnen die de commit stage doorstaan. De pipeline start geen tweede run van de acceptatietests, want die draaien al. Hij zet de candidates ook niet in een wachtrij: als hij ze allemaal testte, zou hij steeds verder achterlopen op wat de developers doen. Zodra de acceptatie vrijkomt, neemt ze de meest recente candidate, hier nummer 5. Nummer 2 wordt nooit afzonderlijk getest. Op één enkele trunk bevat candidate 5 de wijzigingen van nummer 2.

Farley beschrijft elf jaar later dezelfde werkwijze, op een financieel handelsplatform waarvan hij de ontwikkeling leidde. De acceptatie duurde minder dan 40 minuten, en in die tijd leverde de commit stage een stuk of tien candidates op. Kwam de acceptance stage vrij, dan werd de meest recente candidate gedeployed. Zo werden wijzigingen gebundeld, en liep de acceptatie geen achterstand op die ze nooit meer had ingehaald (Continuous Delivery Pipelines, p. 131).

Tweede regel: de acceptance stage is als geheel exclusief. De vier stappen volgen elkaar op voor dezelfde candidate (Continuous Delivery Pipelines, p. 65). Humble en Farley beschrijven een instantie van het systeem die schoon wordt aangemaakt aan het begin van de acceptatietestrun, door al die tests wordt gebruikt en aan het eind wordt gestopt (Continuous Delivery, p. 219 en 220).

Reserveer je alleen de deployment, en niet de hele reeks, dan kan er tussen de deployment en de tests van de eerste candidate een andere worden gedeployed. De testresultaten dragen dan de naam van de ene candidate, maar valideren een andere.

Onaf werk op de hoofdbranch: als laatste aansluiten, of een feature toggle

Meerdere keren per dag integreren betekent code committen die nog niet af is. Humble en Farley geven drie manieren om de trunk toch klaar voor productie te houden (Continuous Delivery, p. 347 tot 349):

• de nieuwe functionaliteit verbergen zolang ze niet af is: de code is gedeployed, maar niets leidt ernaartoe;
• elke wijziging in kleine stappen doen, die elk klaar zijn voor productie;
• bij een grootschalige wijziging, branch by abstraction: een abstractielaag vóór het deel dat vervangen moet worden, de nieuwe implementatie naast de oude bouwen, en daarna de oude verwijderen.

De feature toggle komt pas na die technieken, als geen ervan volstaat. Wanneer hij gerechtvaardigd is, en welke fouten hem gevaarlijk maken, lichten we toe in ons artikel over feature toggles.

Hoe wij werken

We werken op één trunk, met een pipeline die bij elke commit zijn oordeel geeft. AI is een van onze tools, binnen een aanpak waarin elke wijziging wordt gecontroleerd door geautomatiseerde tests.

Voor de ontwikkeling van software op maat werken we tegen een vast budget, aan het einde van elke maand gefactureerd voor het geleverde werk. Uw applicatie is binnen een maand bruikbaar. Uw teams gebruiken haar vanaf de eerste maand, en dat gebruik bepaalt wat we de maand erna ontwikkelen.

En om ervoor te zorgen dat wat vorige maand werkte, ook deze maand werkt, hanteren we de Nulregressiegarantie: elke regressie wordt verholpen en afgedekt door een geautomatiseerde test, zodat ze niet terugkomt, zonder meerkosten.

Verder lezen

In onze gids vindt u de vragen die u moet stellen voordat u een offerte voor softwareontwikkeling tekent.

Wilt u software laten ontwikkelen, en wilt u dat die zo gebouwd wordt? Zullen we kennismaken?

Bronnen

De vertalingen van Engelse citaten zijn van ons.

• MinimumCD.org, lijst van de minimale praktijken van Continuous Delivery en continuous integration: https://minimumcd.org/
• MinimumCD, “Agentic CD”: https://beyond.minimumcd.org/docs/agentic-cd/
• Bryan Finster, “AI broke your code review, here’s how…”: https://bryanfinster.substack.com/p/ai-broke-your-code-review-heres-how
• Bryan Finster, “Code review is not for preventing defects”, LinkedIn-bericht, 24 september 2026: https://www.linkedin.com/feed/update/urn:li:activity:7508842769285795842/
• DORA, “Trunk-based development”: https://dora.dev/capabilities/trunk-based-development/
• DORA, “Working in small batches”: https://dora.dev/capabilities/working-in-small-batches/
• DORA, Accelerate State of DevOps 2024, p. 39 en 40: https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf
• Jez Humble en David Farley, Continuous Delivery, Addison-Wesley, 2010: p. 113 en 114 (binaries maar één keer bouwen), p. 118 en 119 en figuur 5.6 (volgorde van de stages, de meest recente candidate), p. 119 (stop the line), p. 219 en 220 (één instantie per run van de acceptatietests), p. 347 tot 349 (de applicatie klaar voor productie houden, branch by abstraction).
• Dave Farley, Continuous Delivery Pipelines, 2021: p. 44 (branchingstrategie, elke 10 à 15 minuten mergen), p. 52 en 121 (commit stage onder de 5 minuten), p. 56 en 57 (herstellen of terugdraaien, de wijziging van een afwezige collega terugdraaien), p. 58 (release candidate), p. 60 (artifact repository), p. 65 (stappen van de acceptatie), p. 73 en 74 (handmatige tests), p. 131 (acceptance stage en de meest recente candidate).