Selbsttest: Wie Trunk-based ist mein Workflow?

Bis vor kurzem hatte ich eine naive Vorstellung von Trunk-based Development: alle Commits direkt auf main, und sobald CI grün ist, wird auf Produktion deployed. Meine Interpretation war, Branches seien verpönt, selbst kurzlebige Feature-Branches und Release-Branches erst recht.

Geplant war ein Blog-Artikel, in dem ich schreiben wollte, warum ich das für nicht sinnvoll halte. Bei meiner Recherche habe ich dann jedoch lernen dürfen, dass ich ziemlich daneben lag und die Definition von Trunk-based Development keinesfalls so naiv ist, wie ich dachte:

Release-Branches sind sogar ausdrücklich vorgesehen und kurzlebige Branches, sogar mit Review, sind auch der Normalfall.

Zwar habe ich nie in einem Projekt mitgearbeitet, das von sich behauptet hat, Trunk-based zu arbeiten. Rückblickend war der Workflow einiger dieser Projekte sehr wohl Trunk-based Development. Und meine eigenen Projekte kommen dem Ideal des Trunk-based Development sehr nahe.

Um Workflows genauer einzuordnen, habe ich einen Selbsttest gemäß trunkbaseddevelopment.com gebaut. Gefragt wird nach dem, was im Alltag eines Teams passiert, nicht danach, wie das Team seinen Workflow nennt. Fragen, Optionen und Gewichtung entsprechen meinem aktuellen Recherche-Stand und wahrscheinlich nicht der absoluten Wahrheit. Vertiefungen zu den einzelnen Fragen und auch einzelne kritische Anmerkungen folgen in einer Artikelserie, an der ich gerade schreibe.

_{(Es werden keine Daten gespeichert oder übertragen; die Auswertung läuft vollständig im Browser.)}

1. Wie lange lebt ein typischer Entwicklungsbranch bis zum Merge nach main?

Wartezeit auf Review und Freigabe zählt mit.

Es gibt keinen Entwicklungsbranch, ich committe direkt auf main. Wenige Stunden bis zu zwei Tagen. Mehrere Tage bis etwa eine Woche. Wochen oder länger.

2. Wie oft integriert ein einzelner Entwickler Änderungen nach main?

Pro Entwickler oder KI-Agent, nicht das ganze Team.

Mehrmals täglich. Etwa einmal täglich. Ein paar Mal pro Woche. Seltener, meist wenn ein Feature fertig ist.

3. Was muss erreicht sein, damit eine Änderung nach main darf? Jeder kleine, fertige Schritt mit grünem lokalen Build, auch ohne sichtbaren Nutzen für den Kunden. Ein nutzbarer Teilschritt eines größeren Vorhabens. Das vollständige Feature. Jeder Commit, auch unfertige; der Build darf zwischendurch rot sein.

4. Wann wird eine Änderung von einem anderen Menschen geprüft? Beim Schreiben (Pair Programming, KI-Review) oder vor dem Merge innerhalb von Minuten. Zügig nach der Integration, oder je nach Risiko der Änderung: kleine direkt, riskante erst nach Review (Ship / Show / Ask). Vor jedem Merge, meist innerhalb von Stunden. Vor jedem Merge, und das dauert in der Regel Tage.

5. Wie schnell werden offene fachliche Fragen während der Entwicklung entschieden? Sofort, ich oder das Team entscheiden selbst. Meist am selben Tag. Innerhalb einiger Tage. Oft erst nach Wochen.

6. Wie viele Entwicklungsbranches sind im Team gleichzeitig offen, verglichen mit der Zahl der Entwickler und KI-Agenten?

Release-Branches zählen hier nicht.

Weniger, oft gar keiner. Etwa einer pro Entwickler oder Agent. Mehr, weil Branches auf Review oder Entscheidungen warten. Ein Vielfaches.

7. Mit welcher Technik bleibt unfertige Funktionalität auf main unsichtbar? Feature-Toggles, die neue Funktionen zur Laufzeit abschalten. Keystone-Interface oder Branch by Abstraction: alles ist da, nur der Zugang fehlt noch. Nur rückwärtskompatible Vorarbeiten wie neue Felder oder Endpunkte; der sichtbare Teil bleibt im Branch. Gar keine; unfertige Funktionalität bleibt vollständig im Branch.

8. Wie werden voneinander abhängige Änderungen gehandhabt? Klein schneiden; jeder Schritt landet auf main, bevor der nächste beginnt, bei Bedarf hinter Flag oder Abstraktion. Meist klein geschnitten; wird ein Branch doch zu groß, werden fertige Teile herausgelöst und vorab integriert, gelegentlich als Stacked PRs. Als Regel aufeinander aufbauende Branches (Stacked PRs, Branches von Branches), die am Ende nacheinander gemergt werden. Alles zusammen in einem Branch oder einem Integrationsbranch des Vorhabens, bis das Ganze fertig ist.

9. Wie lange dauert die automatisierte Prüfung einer Änderung? Wenige Minuten. Bis etwa 30 Minuten. Länger als 30 Minuten. Es gibt kaum automatisierte Tests; geprüft wird von Hand.

10. Wofür werden Branches genutzt, die länger als eine Woche leben? Gar nicht. Für Experimente, deren Code am Ende meist verworfen wird. Für Architekturumbauten, die später integriert werden sollen. Für normale Feature-Entwicklung.

11. Wie läuft die Arbeit in den Tagen vor einem Release? Wie an jedem anderen Tag; Integrationen nach main gehen im gleichen Tempo weiter. Riskante Änderungen warten, kleine gehen weiter nach main. Es gibt einen Code Freeze: main ist für neue Funktionen gesperrt, bis das Release draußen ist. Fertige Features werden vor dem Release wieder aus main entfernt oder zurückgehalten.

12. Wie oft holt sich ein Entwickler den aktuellen Stand von main in seine Arbeitskopie? Mehrmals täglich, auch ohne Anlass. Mindestens täglich. Kurz vor dem Merge, um Konflikte aufzulösen. Selten; Konflikte werden beim Merge des fertigen Features gelöst.

13. Wie viele Menschen arbeiten gleichzeitig auf demselben Entwicklungsbranch? Es gibt keinen Entwicklungsbranch. Einer, oder ein Pair, gegebenenfalls mit seinen KI-Agenten. Mehrere, wenn sie am selben Feature arbeiten. Das ganze Team teilt sich einen Branch pro Vorhaben oder Release.

14. Wie kommt eine Korrektur für einen bereits ausgelieferten Stand zustande? Auf main korrigiert und ausgeliefert; einen separaten Stand gibt es nicht. Auf main korrigiert und dann per Cherry-pick auf den Release-Branch übernommen. Auf dem Release-Branch korrigiert und dann nach main zurückgemergt. Auf dem Release-Branch wird korrigiert und auch weiterentwickelt; main wird später oder gar nicht nachgezogen.

15. Wie groß ist ein typisches Backlog-Item, bis es nach main darf? Wenige Stunden Arbeit, ein dünner Schnitt durch alle Schichten. Ein bis zwei Tage. Mehrere Tage bis eine Woche. Länger, oft geschnitten nach Schichten (erst Backend, dann Frontend).

16. Wie läuft der lokale Build, bevor eine Änderung gepusht wird? Kompilieren, Unit-Tests und Smoke-Test in etwa einer Minute; den Rest prüft die CI vor dem Merge. Alle Tests lokal, weil sie ohnehin in wenigen Minuten durchlaufen. Ein lokaler Build ist Pflicht, dauert aber zehn Minuten oder länger; deshalb wird seltener gepusht. Kein fester lokaler Build; gepusht wird, um zu sehen, ob die CI grün wird.

17. Was passiert, wenn der Build auf main rot ist? Revert oder Fix innerhalb von Minuten; das Team arbeitet vom letzten grünen Stand weiter. Der Verursacher behebt es zügig, die anderen warten so lange. main bleibt oft Stunden oder Tage rot. main ist regelmäßig rot, niemand fühlt sich zuständig.

18. Wer darf welchen Code ändern, und wonach entscheidet ein Review? Jeder darf überall ändern; Reviews lehnen nur aus veröffentlichten, objektiven Gründen ab. Es gibt zuständige Teams pro Bereich, aber jeder darf dort Änderungen zum Review stellen. Nur die Zuständigen ändern ihren Bereich; andere müssen sie bitten. Reviews lehnen auch nach Geschmack oder Zuständigkeit ab.

19. Gegen welchen Stand wird eine Änderung geprüft, bevor sie auf main landet? Gegen den Stand, den main beim Landen haben wird (Merge-Queue oder spekulativer Merge). Der Branch wird vor dem Merge auf den main-Stand gebracht, danach läuft die CI erneut. Die CI lief nur auf dem Branch-Stand, der inzwischen hinter main liegen kann. Vor dem Merge läuft keine CI.

20. Wie schnell könnte der aktuelle Stand von main ausgeliefert werden?

Gemeint ist die technische und qualitative Bereitschaft, unabhängig davon, ob ein Release gerade erlaubt, angekündigt oder freigegeben ist.

Jede grüne Änderung geht automatisch nach Produktion (Continuous Deployment). Jederzeit innerhalb etwa einer Stunde; zwischen grüner CI und Deploy sind keine weiteren Schritte nötig. Innerhalb eines Tages, nach einer kurzen manuellen Prüfung. Erst nach einer manuellen Test- oder Stabilisierungsphase von Tagen oder Wochen.

Was das Ergebnis bedeutet und was nicht
#

Der Umsetzungsgrad beschreibt nach meinem Verständnis, wie viele der Praktiken, die trunkbaseddevelopment.com für Trunk-based Development nennt, ein Team im Alltag tatsächlich umsetzt, gewichtet nach ihrer Bedeutung für kurze Integrationsabstände. Er ist eine Selbsteinschätzung, kein Messwert: Der Test fragt nur nach dem, was mir dafür typisch erscheint, und nur so ehrlich, wie geantwortet wird. Dies soll auch kein Qualitätsmaß sein: Ein hoher Wert ist nicht „besser“ als ein niedriger, denn vermutlich kommt es mehr darauf an, welche Arbeitsweise zum jeweiligen Kontext passt. Wer bewusst mit langlebigen Feature-Branches arbeitet, bekommt hier einen niedrigen Wert und kann trotzdem einen gut funktionierenden Workflow haben.

Dieser Artikel ist mit Unterstützung von KI entstanden.

Was das Ergebnis bedeutet und was nicht#

Was das Ergebnis bedeutet und was nicht
#