11 Min. Lesezeit
Sébastien Nobour
Gründer von DEVEDANOS
Trunk-Based Development lässt sich in einem Satz zusammenfassen: Alle integrieren ihre Arbeit in einen einzigen Branch, mehrmals am Tag. Was es auf Dauer tragfähig macht, in einem zweiten: eine schnelle Deployment-Pipeline, deren Urteil endgültig ist.
KI-Agenten, die Code schreiben und committen, ändern an diesen Regeln nichts. Sie machen sie noch notwendiger.
Der Trunk ist der Hauptbranch, auch main oder mainline genannt. Beim Trunk-Based Development merget jeder Entwickler seine Arbeit mindestens einmal am Tag dorthin, manchmal öfter. Legt er Branches an, leben sie in der Regel höchstens ein paar Stunden, und im Team sind nie mehr als drei gleichzeitig aktiv. Ein Feature-Branch dagegen enthält Tage oder Wochen Arbeit (DORA, „Trunk-based development“).
MinimumCD macht daraus eine Mindestbedingung für Continuous Integration: Die Arbeit wird mindestens einmal am Tag in den Trunk integriert.
Farley geht weiter. Seine ideale Branching-Strategie besteht aus zwei Wörtern: „Don’t Branch!“ Wenn es überhaupt Branches gibt, sollen es nur wenige sein, winzig und kurzlebig, und sie sollen mindestens einmal am Tag gemergt werden. Wenn ein Team gut arbeitet, merget es alle 10 bis 15 Minuten (Continuous Delivery Pipelines, 2021, S. 44).
Der Unterschied liegt also nicht im Werkzeug. Er liegt darin, wie lange eine Änderung abseits der anderen lebt.
Ein langlebiger Branch verzögert die Integration. Solange er lebt, entwickelt sich der Trunk ohne ihn weiter, und er sich ohne den Trunk. Die beiden driften auseinander. Am Tag des Merges muss alles zusammengeführt werden, was sich auf beiden Seiten geändert hat.
Humble und Farley beschreiben das Versprechen und was daraus wird. Das Versprechen: schneller vorankommen, indem man große Änderungen auf einem Branch macht und am Ende alles zurückmergt. In der Praxis wird genau dieses Zurückmergen zum schwierigen Teil, und je größer die Änderung, desto härter der letzte Merge. Sie fassen es in einem Satz zusammen: Je überzeugender der Grund für einen Branch erscheint, desto weniger sollte man ihn anlegen (Continuous Delivery, 2010, S. 349). Sie halten außerdem fest, dass eine Anwendung, an der auf Branches gearbeitet wird, nicht kontinuierlich integriert wird (S. 347).
DORA bringt Trunk-Based Development mit besserer Leistung bei Softwareauslieferung und Betrieb in Verbindung, gestützt auf seine Daten aus 2016 und 2017. Dasselbe Programm empfiehlt, weder einen Code Freeze noch eine Integrationsphase zu haben („Trunk-based development“).
Ein kurzlebiger Branch ist auch eine kleine Änderung.
Mehrmals am Tag zu integrieren funktioniert nur, wenn jede Integration schnell geprüft wird. Das ist die Aufgabe der Deployment-Pipeline.
Die Commit-Stage kompiliert den Code, führt die schnellen Tests aus und gibt dem Entwickler in weniger als 5 Minuten ihr Urteil (Continuous Delivery Pipelines, S. 52 und 121). Ist sie erfolgreich, erzeugt sie den Release Candidate: genau die Einheit, die in Produktion landet, falls sie es so weit schafft (S. 58).
Dieser Kandidat wird nur ein einziges Mal gebaut. Humble und Farley erklären, warum: Wer in jeder Stage neu kompiliert, riskiert, etwas anderes in Produktion zu bringen als das, was getestet wurde (Continuous Delivery, S. 113 und 114).
Der Kandidat wird in einem Artefakt-Repository abgelegt. Farley nennt es die „version of truth“: Was darin liegt, sind genau die Bits und Bytes, die in Produktion deployt werden sollen. Die umgebungsspezifische Konfiguration ist davon getrennt, und keine Version wird für eine bestimmte Umgebung gebaut (Continuous Delivery Pipelines, S. 60).
Die Acceptance-Stage nimmt diesen Kandidaten und folgt immer denselben vier Schritten: die Umgebung konfigurieren, den Kandidaten deployen, prüfen, dass er startet, die Akzeptanztests ausführen (S. 65). Manuelle Tests sind explorativ. Sie betreffen nur Kandidaten, die die Akzeptanztests bereits bestanden haben, und dienen nicht als Regressionstests (S. 73 und 74).
MinimumCD fasst diese Regeln zusammen. Die Pipeline ist der einzige Weg, in eine beliebige Umgebung zu deployen. Das Artefakt ist unveränderlich: Nach dem Commit ändert kein Mensch mehr etwas daran. Die Pipeline entscheidet, ob eine Änderung in Produktion gehen darf, und ihr Urteil ist endgültig.
Hier das Prinzip als Pseudo-Konfiguration, ohne die Syntax eines bestimmten Werkzeugs:
# Pseudo-Konfiguration für diesen Artikel: das Prinzip, kein Werkzeug.
pipeline:
auslöser: jeder Commit auf den Trunk
commit-stage:
angestrebte dauer: unter 5 Minuten
schritte:
- kompilieren
- die schnellen Tests ausführen
- den Kandidaten bauen, ein einziges Mal
- den Kandidaten im Artefakt-Repository ablegen
bei fehler: das Band anhalten
acceptance-stage:
exklusiv: die ganze Stage, vom ersten bis zum letzten Schritt
kandidat: der neueste, der die Commit-Stage bestanden hat
schritte:
- die Umgebung konfigurieren
- den Kandidaten deployen
- prüfen, dass er antwortet
- die Akzeptanztests ausführen
- die Umgebung herunterfahren
bei fehler: das Band anhalten
produktion:
kandidat: der, der die Akzeptanztests bestanden hat
freigabe: von einer Person entschieden (Continuous Delivery)
oder automatisch (Continuous Deployment)
Eine rote Pipeline bedeutet eines: Der Trunk ist nicht mehr bereit für die Produktion. Für Farley hat das für das Team Priorität: den Weg in die Produktion freihalten (Continuous Delivery Pipelines, S. 57). MinimumCD sagt es noch knapper: Ist die Haupt-Pipeline rot, ruht jede Arbeit an Features.
Humble und Farley nennen das „Stop the Line“, das Band anhalten: Schlägt ein Teil der Pipeline fehl, hält man an (Continuous Delivery, S. 119).
Danach gibt es nur zwei Optionen. Innerhalb von etwa zehn Minuten beheben oder die Änderung reverten (Continuous Delivery Pipelines, S. 56). Und ist der Autor der Änderung nicht da, revertet das Team sie an seiner Stelle (S. 57).
git switch main && git pull
git revert --no-edit <verursachender-commit>
git push
Der Revert ist selbst ein Commit. Er durchläuft die Pipeline wie jeder andere, und die Historie hält fest, was passiert ist.
Der DORA-Bericht 2024 hat etwas gemessen, womit seine Autoren nicht gerechnet hatten. Steigt die Nutzung von KI um 25 %, sinkt der Durchsatz der Auslieferung um schätzungsweise 1,5 % und die Stabilität um schätzungsweise 7,2 % (Accelerate State of DevOps 2024, S. 39 und 40). Das sind Schätzungen aus einer Umfrage: eine Korrelation, kein Beleg für einen kausalen Zusammenhang.
Die Autoren stellen eine Hypothese auf. Mit KI lässt sich in derselben Zeit viel mehr Code produzieren. Es ist also möglich, ihrer Ansicht nach sogar wahrscheinlich, dass die Änderungen größer werden. Und ihre Daten zeigen seit Jahren, dass große Änderungen langsamer sind und häufiger Instabilität verursachen (S. 40).
Stimmt die Hypothese, ist die Antwort kein neues Werkzeug. Sie ist die Disziplin kleiner Batches, angewandt auf Agenten wie auf Menschen. DORA beschreibt die Arbeit in kleinen Batches im Übrigen als Sicherheitsnetz für die Einführung von KI („Working in small batches“).
MinimumCD leitet daraus konkrete Regeln für Agenten ab („Agentic CD“):
Ein Agent hat also nicht mehr Rechte als ein Entwickler. Die Pipeline bleibt der einzige Weg in die Produktion.
Bleibt das Code Review. Bryan Finster, Maintainer von MinimumCD, plädiert in „AI broke your code review, here’s how…“ dafür, das menschliche Urteil dem vorzubehalten, was es braucht: dem Verhalten, das im Team vor dem Code festgelegt wird, den Szenarien, die zu Akzeptanztests werden, dem Wissen, das dem Team eigen ist, und der Compliance. In einem LinkedIn-Beitrag vom 24. September 2026 beschreibt er eines seiner besten Teams. Kein Code Review hielt die Auslieferung auf: „Our pipelines reviewed the code“ (unsere Pipelines haben das Code Review gemacht).
Was KI allein gut kann und was es darüber hinaus braucht, damit eine Anwendung im Produktivbetrieb besteht, erklären wir in unserem Artikel darüber, wie man eine App mit KI erstellt.
Mehr Commits bedeuten mehr Kandidaten. Was passiert, wenn die Acceptance-Stage belegt ist und neue Kandidaten ankommen?
Humble und Farley antworten mit einem Beispiel (Continuous Delivery, S. 118 und 119, Abbildung 5.6). Die Akzeptanztests laufen auf Kandidat 1. Währenddessen kommen andere Änderungen an und bestehen die Commit-Stage. Die Pipeline startet keinen zweiten Lauf der Akzeptanztests, da diese bereits laufen. Sie reiht die Kandidaten auch nicht in eine Warteschlange ein: Würde sie alle testen, geriete sie immer weiter in Rückstand gegenüber dem, was die Entwickler tun. Wird die Acceptance-Stage frei, nimmt sie den neuesten Kandidaten, hier Nummer 5. Nummer 2 wird nie für sich allein getestet. Auf einem einzigen Trunk enthält Kandidat 5 dessen Änderungen.
Farley beschreibt elf Jahre später dieselbe Arbeitsweise, auf einer Finanzbörse, deren Entwicklung er geleitet hat. Die Akzeptanztests dauerten weniger als 40 Minuten, und in dieser Zeit erzeugte die Commit-Stage rund zehn Kandidaten. Wurde die Acceptance-Stage frei, wurde der neueste Kandidat deployt. So wurden Änderungen gebündelt, und die Acceptance-Stage baute keinen Rückstand auf, den sie nie wieder aufgeholt hätte (Continuous Delivery Pipelines, S. 131).
Zweite Regel: Die Acceptance-Stage ist als Ganzes exklusiv. Ihre vier Schritte laufen für denselben Kandidaten unmittelbar nacheinander ab (Continuous Delivery Pipelines, S. 65). Humble und Farley beschreiben eine Instanz des Systems, die zu Beginn des Akzeptanztestlaufs frisch erzeugt, von allen diesen Tests genutzt und am Ende heruntergefahren wird (Continuous Delivery, S. 219 und 220).
Reserviert man nur das Deployment und nicht die ganze Abfolge, kann zwischen dem Deployment des ersten Kandidaten und seinen Tests ein anderer deployt werden. Die Testergebnisse tragen dann den Namen des einen Kandidaten, validieren aber einen anderen.
Mehrmals am Tag zu integrieren heißt, Code zu committen, der noch nicht fertig ist. Humble und Farley nennen drei Wege, den Trunk trotzdem bereit für die Produktion zu halten (Continuous Delivery, S. 347 bis 349):
Der Feature-Toggle kommt nach diesen Techniken, wenn keine davon ausreicht. Wann er gerechtfertigt ist und welche Fehler ihn gefährlich machen, erläutern wir in unserem Artikel über Feature-Toggles.
Wir arbeiten auf einem einzigen Trunk, mit einer Pipeline, die bei jedem Commit ihr Urteil fällt. KI gehört zu unseren Werkzeugen, innerhalb eines Ansatzes, bei dem jede Änderung durch automatisierte Tests geprüft wird.
Bei der Entwicklung individueller Software arbeiten wir zu einem festen Budget, das am Ende jedes Monats für die geleistete Arbeit abgerechnet wird. Ihre Anwendung ist innerhalb eines Monats nutzbar. Ihre Teams arbeiten ab dem ersten Monat damit, und diese Nutzung entscheidet, was wir im Folgemonat entwickeln.
Und damit das, was im letzten Monat funktioniert hat, auch in diesem Monat noch funktioniert, wenden wir die Null-Regressions-Garantie an: Jede Regression wird behoben und durch einen automatisierten Test abgesichert, damit sie nicht wiederkehrt, ohne Aufpreis.
In unserem Leitfaden finden Sie die Fragen, die Sie stellen sollten, bevor Sie ein Angebot für Softwareentwicklung unterschreiben.
Möchten Sie eine Software entwickeln lassen, und soll sie so gebaut werden? Sprechen wir darüber?
Die Übersetzungen englischer Zitate stammen von uns.
Was ist ein Feature Flag? Vier Arten von Toggles, was Sie versuchen sollten, bevor Sie einen hinzufügen, und sieben Anti-Patterns, durch die nie getesteter Code läuft.
App entwickeln lassen: Mit welchem Budget rechnen? Der Betrag allein reicht nicht: Setzen Sie auf ein Ziel statt auf eine Liste, mit Nutzern ab dem ersten Monat.
Prädiktiver oder adaptiver Ansatz? Die eigentliche Trennlinie verläuft nicht zwischen V-Modell und agilem Vorgehen, sondern zwischen Vorhersagen und Anpassen. Was das für Software bedeutet.