Wie funktioniert trunk-based Development?

Geschätzte Lesezeit: 12 Minuten

Smalltalk über trunk-based Development

Als Technical Lead habe ich in verschiedenen Unternehmen regelmässig Bewerbungsgespräche mit Software Engineers geführt und mir dabei mit der Zeit angewöhnt, dort bereits zu erwähnen, wenn im Engineering-Team trunk-based entwickelt wird. Die Reaktionen darauf lassen mich immer wieder innerlich schmunzeln, denn sie schwanken zwischen belustigt, erstaunt, perplex, neugierig oder bisweilen erfreut. Gar nicht so selten werde ich aufgeklärt, warum trunk-based Development nicht funktionieren kann oder sogar gefährlich und geradezu Teufelswerk sei. Ich erlaube mir dann die dezente Bemerkung, dass sowohl kleinere als auch grössere Engineering-Teams diese Methode bereits seit Jahren äusserst erfolgreich anwenden und sie mitnichten etwas Neues oder Unerprobtes darstellt.

Bei diesen Gesprächen fällt mir allerdings stets ein Muster auf, denn sehr oft wird nur die Methode des trunk-based Developments isoliert betrachtet. Und in diesem Fall muss ich den Kritikern Recht geben: Direkt auf den Main-Branch zu pushen, ohne CI/CD-Umgebung, ohne automatisierte Tests und ohne Vier-Augen-Prinzip darf durchaus als Harakiri bezeichnet werden.

Es geht in diesem Artikel deshalb nicht ausschliesslich um trunk-based Development, sondern um eine Technik, welche nur im Zusammenspiel mit einer Reihe von Grundvoraussetzungen funktioniert und eine bestimmte Teamstruktur sowie -kultur voraussetzt.

Wie funktioniert trunk-based Development?

Das Grundprinzip von trunk-based Development ist erstaunlich simpel: anstatt Feature- oder Release-Branches zu verwenden, werden Changes von den Entwicklern direkt auf dem Trunk (auch Main oder veraltet Master genannt) zusammengeführt. Nicht selten findest du in Teams, die trunk-based arbeiten, keinen einzigen Branch, sondern es wird einzig und allein auf dem Main Branch entwickelt.

Code-Changes werden in einem solchen Setup in kurzen, regelmässigen Abständen zusammengeführt und im Normalfall auch direkt automatisiert deployed. Dadurch entstehen keine umfangreichen Änderungshistorien und eine auf kleinen, kontinuierlichen Weiterentwicklungen basierende Arbeitsmethodik mit einem hohen Grad an Automatisierung wird gefördert.

Die Benefits von trunk-based Development

Keine Entwicklungsmethode ist ein Allheilmittel und kommt ohne Vor- und Nachteile aus. Nichtsdestotrotz minimiert oder verhindert trunk-based Development einige der typischen Herausforderungen, die bei anderen Entwicklungsmethoden normalerweise auftreten.

Schnelle Release-Zyklen

In Unternehmen, die mit Git Flow oder eine Variante davon arbeiten, findet man hingegen nicht selten Release-Zyklen von mehreren Wochen bis Monaten. Ein schnelles Handeln, das auf verändernde Marktbedingungen ausgerichtet ist, wird dadurch jedoch stark eingeschränkt. Trunk-based Development unterstützt Unternehmen beim kontinuierlichen, zeitlich unabhängigen Release neuer Funktionalitäten für ihr Produkt.

Wird Software also mit einem MVP-Fokus (Minimum Viable Product) entwickelt, hilft trunk-based Development durch die häufigen Releases beim Erreichen dieser Ziele. Es geht darum, die Bedürfnisse der Benutzer schnellstmöglich zu verstehen, zu befriedigen und gleichzeitig eine kontinuierliche Weiterentwicklung sicherzustellen. Neue Funktionalität kann sofort live gestellt werden, der hohe Grad an Automatisierung unterstützt zusätzlich durch zuverlässig arbeitende Tests und reproduzierbaren (und rollback-fähigen) Deploymentschritten. High-performing Teams, die nach modernen Grundsätzen arbeiten, nutzen daher häufig trunk-based Development, um schnelle Fortschritte bei gleichzeitig hoher Qualität und hohem Lernerfolg erzielen zu können.

Häufiges Committen für stärkeres Commitment

Die hohe Entwicklungsgeschwindigkeit, Pair Programming, automatisierte Tests und damit einhergehende Ansätze wie Test Driven Development sowie schlussendlich die eigenständige Verantwortung für das Deployment bis auf Production stellen hohe Anforderungen an Software Engineers. Ein umfangreiches Verständnis für die verschiedenen, ineinander greifenden komplexen Systeme, wie CI/CD-Pipelines, Infrastructure-as-Code, automatisierte Test-Suiten, Container-Runtime-Environments und vieles mehr, ist nötig, um alle Teile des Puzzles erfolgreich zu einem funktionierenden Service zusammenzusetzen. Das wiederum fördert das Engagement der einzelnen Teammitglieder, denn sie sehen ihren direkten Impact auf die (Weiter-)Entwicklung des Produkts – im positiven wie auch im potentiell negativen Sinne – falls beispielsweise Bugs auftreten.

Das Silodenken zwischen Dev und Ops wird aufgebrochen und die Folge ist ein DevOps-Mindset, in der die Mitarbeitenden Verantwortung übernehmen können und sollen. Daraus resultiert ein tiefergehendes Verständnis aller involvierter Personen für die technischen Prozesse als auch die Businessprozesse, kommunikative Hürden werden abgebaut.

Kontinuierliche und synchrone Code Reviews

Das konstante Integrieren von Code-Changes kommt gezwungenermassen nicht um ein zuverlässiges Review-System herum. Kontinuierlich stattfindende Code-Reviews unterstützen bei einer hohen Code-Qualität sowie beim Knowledge-Sharing zwischen den Software Engineers (was ebenfalls wiederum dabei hilft, Knowledge-Silos vorzubeugen). Ein Vier-Augen-Prinzip erhöht zudem die Geschwindigkeit der Reviews und baut zeitliche Verzögerungen ab, die bei Code Reviews via Pull Requests oft dann entstehen, wenn die Kommunikation nicht direkt erfolgt, sondern über schriftliche Kommentare.

Vermeidung der „Merge conflict hell“

Hand auf’s Herz: wer hat noch nicht geflucht, wenn beim Zusammenführen zweier Branches Unmengen von Merge-Konflikten aufgetaucht sind, die oftmals mühsam manuell aufgelöst werden müssen? Trunk-based Development beendet diese wenig Sinn stiftende, aber zeitintensive Arbeit und legt den Fokus voll und ganz auf das einfache Integrieren der eigenen Code-Changes ohne Kopfschmerzen.

Die Grundlagen

Es ist essenziell zu verstehen, dass trunk-based Development alleine weder ein Allheilmittel ist noch zuverlässig funktionieren wird. Die Arbeitsmethode ist Teil eines Entwicklungsstils, der stark vom Extreme Programming inspiriert ist. Leitgedanke ist ein reaktives, schnelles Development-Team, welches ohne Hindernisse wie langwierige Merges und einem Dschungel von langlebigen, veralteten Feature Branches auskommt. Gerade Letzteres führt nicht selten zu unzähligen unterschiedlichen Entwicklungsständen oder im schlimmsten Fall sogar unklaren Code-Versionen auf den verschiedenen Umgebungen.

Die CI/CD-Umgebung als Herzstück

CI steht in der Marketing-Sprache zwar auch für Corporate Identity, im Engineering-Kontext sprechen wir aber von Continuous Integration. CD bedeutet Continuous Deployment und ist der zweite Schritt in einer CI/CD-Umgebung. Basis für eine solche Umgebung ist eine CI/CD-Software wie beispielsweise die Open-Source-Software Jenkins oder SaaS-Lösungen wie CircleCI oder die in GitLab integrierte CI/CD-Plattform.

In der CI/CD-Umgebung wird bei jedem neuen Git-Commit automatisch ein Prozess (oft Build-Pipeline genannt) gestartet, der im Normalfall die folgenden Schritte automatisiert übernimmt:

  • Es wird ein git clone vom letzten Code-Stand auf dem konfigurierten Branch ausgeführt. Im Fall von trunk-based Development ist das normalerweise der Main Branch.
  • Je nach Programmiersprache wird zuerst ein Build-Artefakt erstellt (bei kompilierten Sprachen wie beispielsweise Java, C++ oder Go). Bei zur Laufzeit interpretierten Programmiersprachen wie Python, Ruby oder PHP wird normalerweise ein Docker-Image erstellt, welches den aktuellsten Code sowie Libraries und weitere Dependencies und Assets beinhaltet.
  • In diesem Docker-Image werden die automatisierten Tests ausgeführt. Schlägt hier ein Test fehl, wird die Ausführung der CI/CD-Pipeline in der Regel abgebrochen, da kein stabiles Deployment garantiert werden kann.
  • Die Code-Changes werden nacheinander in die unterschiedlichen Laufzeitumgebung (development, staging, production) integriert. Das kann beispielsweise der Webserver sein, der den Code für eine Webapp ausführt.
  • Die Integration beinhaltet unter Umständen auch rollback-fähige Datenbank-Deployments, wenn beispielsweise das Datenbank-Schema geändert wurde.
  • Im Fall einer automatisierten Server-Infrastruktur wird der Code für das Infrastruktur-Provisioning und -Management normalerweise ebenfalls mit integriert, insbesondere sofern ein Infrastructure-as-Code Ansatz verfolgt wird.

Die Laufzeit all dieser Schritte sollte idealerweise so kurz wie möglich gehalten werden, damit die Pipelines keine Engstelle im Deployment-Prozess darstellen.

Fail Fast: automatisierte Tests

Ich habe es bereits am Anfang dieses Artikels erwähnt: trunk-based Development mit direktem Deployment auf die Production-Umgebung wäre Harakiri. Es ist Job der CI/CD-Pipeline dafür zu sorgen, dass bei jedem Commit die automatisierten Tests ausgeführt werden. Schlägt ein Test fehl, wird die weitere Ausführung der Pipeline abgebrochen und der Build befindet sich im Status failed.

Automatisierte Tests sorgen dafür, dass relevante Bestandteile im Code nachhaltig getestet werden, ohne sich in Implementierungsdetails zu verlieren und damit die Costs of maintenance in die Höhe und die Entwickler in den Wahnsinn treiben. Die verschiedenen Level wie Unit Tests, Integration Tests oder End-to-end Tests werden in der CI/CD-Pipeline idealerweise in der Reihenfolge entsprechend ihrer Kosten im zeitlichen Sinne ausgeführt. Dieser Fail Fast-Ansatz hat das Ziel, dass wir als Entwickler möglichst schnell Feedback erhalten, wenn ein Test fehlgeschlagen ist und die Pipeline abgebrochen wurde. Es macht keinen Sinn, zuerst die teuren End-to-end Tests auszuführen, nur um im Anschluss nach minutenlanger Wartezeit an einem simplen Unit-Test zu scheitern.

Als Entwickler und im Kontext der Quality Assurance möchte ich wissen, ob meine Code Changes bestehende Funktionalitäten beeinträchtigen könnten. Gleichzeitig verfolgen agile Entwicklungsansätze vor allem das Ziel, schnell und flexibel auf Veränderungen zu reagieren und neue Funktionalität einfach und sicher auszurollen. Manuelle (sprich von Personen durchgeführte) Tests sind dafür offensichtlich ungeeignet, da sie einerseits naturbedingt selbst fehleranfällig sind und andererseits keine Synchronität gegeben ist. Automatisierte Tests hingegen werden von der CI/CD-Software stupide immer nach dem selben Schema ausgeführt und stellen – gut umgesetzt – sicher, dass der getestete Workflow auch nach Änderungen immer noch wie in den Tests definiert funktioniert.

Sicherheit durch Code Reviews

Bei Git Flow sind langlebige Feature- und Release-Branches Teil des Konzepts. Aufgrund ihrer bisweilen schwer zu überschauenden Komplexität und gegenseitigen Abhängigkeiten können sie eine ernstzunehmende Schwachstelle in der Qualitätskontrolle darstellen. Die kleineren Batches an Code-Changes in einem CI/CD-basierten Ansatz sind bei einem Review hingegen deutlich realistischer zu verstehen. Noch einen Schritt weiter geht hier der ebenfalls vom Extreme Programming inspirierte Ansatz des Pair Programmings, bei dem zwei Entwickler kontinuierlich zusammenarbeiten und ein permanentes Vier-Augen-Prinzip gewährleistet ist. Fehler können so schon entdeckt werden, bevor sie überhaupt in der Codebase landen und daraus resultierende Irrwege in der Entwicklung vermieden werden.

Egal ob per Code Review oder durch Pair Programming: wichtig ist auch hier die Synchronität, um einen schnellen, kontinuierlichen Development-Flow sicherstellen zu können. Pair Programming hat an dieser Stelle (neben einigen anderen Vorteilen) etwas die Nase vorn, da es keinen Unterbruch im Workflow gibt. Zwei Entwickler schreiben gemeinsam Code, verhindern durch das Vier-Augen-Prinzip Fehler in der Codebase, lassen lokal die Test-Suite laufen, pushen ihren Change und müssen nur noch darauf achten, dass die CI/CD-Pipeline fehlerfrei durchlaufen wird. Der Zeitaufwand: wenige Minuten ab dem Commit gegenüber oftmals Stunden bis Tagen für den klassischen Git Flow mit Pull Requests und aufwändigen Code Merges.

Containerbasierte Laufzeitumgebung

Auch wenn es nicht notwendigerweise Docker sein muss (auch Podman oder Buildah sind Laufzeitumgebungen, die als Container auf Betriebssystemebene ausgeführt werden), beschränke ich mich hier auf diesen Platzhirsch. Services, die als Container-Image vorliegen, können als Teil der CI/CD-Pipeline verhältnismässig einfach auf die produktive Umgebung ausgerollt werden, beispielsweise innerhalb eines Kubernetes-Clusters, Amazon ECS oder einer ähnlichen Infrastruktur. Containerbasierte Laufzeitumgebungen sind kein Must-have, sie erleichtern allerdings die Arbeit mit einer CI/CD-Umgebung deutlich und unterstützen dadurch indirekt trunk-based Development.

Infrastructure-as-Code

Die Infrastruktur als Teil der Codebase zu sehen, ist mittlerweile Best Practice in der Ops-Welt. Hierbei wird das Management und Provisioning von Infrastruktur-Resourcen wie Servern, Datenbanken oder DNS-Konfigurationen von Tools wie Terraform oder Pulumi übernommen. Die Konfiguration liegt als deklarativer Code geschrieben vor und nutzt die APIs von Cloud-Plattformen wie Google Cloud oder AWS, um inkrementell Changes an der Infrastruktur durchzuführen.

Als Teil der CI/CD-Pipeline werden auch diese Änderungen an der Infrastruktur automatisiert ausgerollt und sind damit Teil des gesamten Ökosystems, welches trunk-based entwickelt wird.

Modulare Software-Architektur

Keine zwingende Voraussetzung, aber durchaus hilfreich ist eine modular angelegte Applikations-Architektur. Ob Microservice-Architektur, SOA-Architektur oder monolithische Architektur – trunk-based Development funktioniert grundsätzlich mit jedem dieser Ansätze. Eine modulare und auf kleinere Services ausgerichtete Architektur hilft jedoch ganz klar, Abhängigkeiten zu minimieren, die Laufzeiten für Test-Suiten zu verringern und das Deployment selber deutlich zu vereinfachen.

Der Faktor Mensch

Nicht unterschätzt werden sollte die Rolle der Menschen, die in einem rund um die CI/CD-Umgebung aufgebauten Team arbeiten. Insbesondere Techniken wie trunk-based Development, Pair Programming, TDD oder die Übernahme von Verantwortung auch über einen Pull Request hinaus sind letztlich Vorgehensweisen, die jeden Tag aktiv gelebt werden müssen. Der Impact der Teamkultur solcher Engineering-Teams auf ihren eigenen Erfolg kann daher durchaus als signifikant bezeichnet werden.

High-performing Teams ziehen Personen an, die bereit sind, über den Tellerrand hinauszuschauen. Das Denken in Silos funktioniert dort nicht, die Bereitschaft zur Übernahme von Verantwortung ist eine Grundvoraussetzung. Verantwortung zu übernehmen bedeutet dabei vor allem, sich als Software Engineer stets bewusst zu sein, gemeinsam mit dem Pair Programming Partner für das Schreiben von skalierbaren und automatisierten Tests, gut verständlichem Code und dem Rollout dieses Codes zuständig zu sein. Erst wenn nach den eben genannten Schritten ein Release erfolgreich abgeschlossen ist, ist die grundsätzliche Arbeit getan. Schlägt die CI/CD-Pipeline hingegen fehl, ist es die Aufgabe der Entwickler, dafür zu sorgen, dass das darunterliegende Problem schnellstmöglich behoben wird.

Man kann zusammenfassend sagen, dass sich für die Arbeit in solchen Teams insbesondere Menschen begeistern können, die den pragmatischen Spagat zwischen Weitsicht und Detailverliebtheit meistern können, gerne teamübergreifend arbeiten sowie aktiv kommunizieren können und häufig kollaborieren möchten. Ein paar der Teammitglieder sollten erfahrene Senior Software Engineers sein, die mit den weniger erfahrenen Kollegen regelmässig gemeinsam zusammenarbeiten und die Do’s und Don’t’s rund um trunk-based Development mit ihnen teilen können.

Best Practices

Nachdem wir nun einen Blick auf die Grundlagen geworfen haben, die für eine funktionierende trunk-based Development-Umgebung wichtig sind, geht es jetzt primär um die nicht minder relevanten Soft Facts. Trunk-based Development funktioniert nur innerhalb einer entsprechenden Teamkultur mit den richtigen Tools und beim Befolgen einiger Regeln.

Stelle eine hohe Verfügbarkeit der Build-Pipeline sicher

Trunk-based Development geht mit kontinuierlichen neuen Deployments einher und bedingt dementsprechend eine hochverfügbare und funktionsfähige Pipeline für jeden Service. Fehler in der CI/CD-Pipeline können natürlich auftreten, sollten allerdings sofort von den jeweiligen Entwicklern behoben werden. Ebenso sollte die Regel gelten, dass keine neuen Commits auf einen bereits roten Build erfolgen dürfen. Es obliegt hier also den Entwicklern, vor jedem neuen Commit den Zustand der Pipeline zu checken.

Benutze Feature Toggles

Feature Toggles (oder auch Feature Flags) sind ein wichtiges Element beim direkten Arbeiten auf dem Main Branch. In der simpelsten Form handelt es sich um Konfigurationsvariablen, die bestimmte Funktionalitäten softwareseitig aktivieren oder deaktivieren. Statt separate Release-Branches zu verwenden, können damit Teile des Codes von der Ausführung ausgenommen werden. Sie ermöglichen ein einfaches Aktivieren gewisser Funktionalitäten beispielsweise auf der Development- oder Staging Umgebung, während die Production-Umgebung das neue Feature gegebenenfalls noch nicht kennt.

Deploye kontinuierlich kleinere Change-Batches

Mit einer funktionierenden CI/CD-Toolchain kann Continuous Integration bis ins Extreme gelebt und der Code mehrere Male pro Stunde deployed werden. Selbstverständlich gilt für jedes Deployment, dass eine adäquate Menge an automatisierten Tests existiert. Als Minimum sollte sicherlich die Faustregel gelten, wenigstens einmal pro Tag zu deployen, idealerweise jedoch häufiger.

Dahinter steht auch ein psychologischer Effekt: jedes Deployment triggert automatisch auch einen Release bis in die Production Environment. Dieser Workflow sollte jeder Software Engineer im Schlaf kennen und dadurch ein hohes Mass an Vertrauen in die Infrastruktur aufbauen können. Je seltener bis auf Production deployed wird, umso risikoaverser werden die beteiligten Personen. Ist diese Art des Deployments hingegen Business as usual, sinkt die Angst beziehungsweise steigt das Vertrauen und damit auch die Motivation, selber einen Beitrag zur Weiterentwicklung der Software zu leisten.

Schreibe. Automatisierte. Tests.

Ich vermute, dass die eingangs erwähnte Aversion gegenüber trunk-based Development auch von einem gewissen Respekt vor der Komplexität der dafür notwendigen automatisierten Test-Suite herrührt. Es gibt leider immer noch viel zu viele Applikationen, geschrieben von zu vielen Entwicklern, die überhaupt keine Tests beinhalten.

Klar ist: das Auseinandersetzen mit den notwendigen Techniken wie Mocks oder Stubs, Fixtures oder Factory Pattern sowie dem Verständnis der unterschiedlichen Testarten in der Testpyramide erfordert einen gewissen Zeitaufwand. Und natürlich ist es interessanter, immer neue Features rauszuballern anstatt sich mit den potentiell negativen Konsequenzen des eigenen Codes zu beschäftigen (tröstende Bemerkung: das ist ein nur allzu menschliches Verhalten und wird als kognitive Dissonanz bezeichnet). Die unbequeme Wahrheit ist jedoch: Als Entwicklerin oder Entwickler in einem professionellen Umfeld gehört es zu unserer Pflicht, auch die Skalierbarkeit, Wartbarkeit, Erweiterbarkeit und Robustheit unseres Codes zu gewährleisten. Richtig eingesetzt sind automatisierte Tests das mächstigste Werkzeug, um diese non-functional Requirements zu erreichen.

Halte deine Build-Pipeline clean und schnell

Nichts ist mühsamer als bei einem neuen Commit  eine Stunde warten zu müssen, bevor das Ergebnis der Build-Pipeline in der CI/CD-Umgebung bekannt ist. Häufig sind lange Build- und Compile-Prozesse oder inperformante Test-Suiten Schuld an der Misere. Versuche die Zeit, die vom Commit bis hin zum erfolgreichen Deployment auf Production vergehen, unter 10-15 Minuten zu halten und investiere konsequent Zeit, falls sich diese Zeiten verlängern. Build-Pipelines sind wie Demokratien: wir müssen ein Auge auf sie haben und sie pflegen, sonst werden sie langsam zu einem Problemfall und bremsen die Weiterentwicklung aus.

Nutze keine Branches

Wenn du es schaffst, das Development-Setup in deiner Firma auf einen, zwei oder drei Branches pro Repository zu reduzieren, kannst du auf diese vermutlich auch noch verzichten. Trunk-based Development bedeutet auf dem Trunk zu entwickeln und diese Tatsache solltest du nicht aufweichen. Probiere den Ansatz in einem kleineren Projekt aus, wenn du dir unsicher bist – aber ziehe das Setup so durch, dass es dem eigentlichen Konzept dahinter entspricht.

Eine persönliche Meinung zu trunk-based Development

Es gibt vermutlich Unmengen von Pro-Contra Vergleichen, viele bereits gefasste Meinungen und zum Teil auch eine gewisse Emotionalität in diesem Thema. Am Ende hilft trunk-based Development vor allem dabei, den Fokus eines Entwicklungsteams voll und ganz auf das Entwickeln von Software zu legen. Engineering Teams sind für viele Nicht-Techies nachvollziehbarerweise eine Blackbox, und zwar eine relativ teure. Das weitverbreitete Verständnis liest sich wie folgt: Da sind diese Entwickler, die bekommen Requirements, setzen diese in Code um, testen den Code und gehen damit live.

Eine rund um Continuous Integration und Continuous Deployment aufgebaute Entwicklungsmethode kommt diesem Grundverständnis relativ nahe. Es ist ausserhalb der Tech-Welt schwer zu verargumentieren, warum komplizierte Releases Stunden oder gar Tage brauchen, was Release Branches oder Tags sind oder wieso es mehrere unterschiedliche Rollen (und damit meist Personen) benötigt, um den Go-Live eines kleinen Features abzuschliessen.

Je einfacher und logischer ein in sich bereits komplexer Prozess ist, umso besser. Trunk-based Development unterstützt dabei und kommt diesem Ideal relativ nahe. Standardtechnologien zu verwenden und Best Practices zu folgen sind ernstzunehmende Erwägungen um nicht in die Builders Trap zu treten, denn auch im Infrastrukturbereich (und dazu zähle ich die CI/CD-Umgebung) trifft man häufig auf komplexe, selbstentwickelte Setups, die entsprechende Kosten für Weiterentwicklung und Maintenance verschlingen, für den Business Case selber allerdings nur eine untergeordnete Rolle spielen.

Trunk-based Development
Trunk-based Development ist im Grunde genommen gar nicht schwer, wenn die richtigen Rahmenbedingungen geschaffen und beachtet werden.

Engineering-Teams neigen nicht selten zu einer gewissen Over-Engineering-Tendenz. Das ist nicht grundsätzlich verwerflich, summiert sich jedoch zum Teil zu einer nicht zu unterschätzenden Menge an zusätzlichem Aufwand und damit einhergehender Komplexität im Tech-Stack. Mit dem für das trunk-based Development nötigen Mindset lässt sich diesem Verhaltensmuster zumindest etwas vorbeugen. Durch die kontinuierlichen Code Reviews, Task Sign-offs und das Vier-Augen-Prinzip wird eine Art Nordstern definiert, der jedes Teammitglied immer wieder an die wichtigsten und relevantesten Kernaufgaben und Ziele erinnert.

Zusammenfassung

Es ist glücklicherweise keine Raketenwissenschaft, einen Development-Prozess aufzubauen, der auf Commits auf dem Main-Branch basiert. Ein paar Grundvoraussetzungen sollten allerdings geschaffen und beachtet werden, um die damit einhergehenden Benefits wie eine höhere Geschwindigkeit oder konstantere Code Reviews möglich zu machen. Die persönliche Einstellung der Mitglieder des Entwicklungsteams spielen eine nicht zu unterschätzende Rolle, denn trunk-based Development bedeutet vor allem eines: Verantwortung übernehmen zu wollen und ein breites Verständnis von Software Entwicklung aufzubauen, in dem der gesamte Lifecycle des Codes ein tragender Bestandteil ist.

Hat man sich jedoch einmal an diese performante und in den allermeisten Fällen unkomplizierte Arbeitsweise gewöhnt, möchte man sie nicht mehr missen. Das Wissen, seine Zeit nicht mit unrelevanten und mühsamen Merge-Prozessen zu vergeuden, ist für den ein oder anderen vielleicht schon Antrieb genug, sich mit modernen Formen des Deployments auseinanderzusetzen.

Letters from Anywhere

Tritt der Community aus Technical Leaders und Software Engineers bei und melde dich für unseren Technical Leadership Newsletter an.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren.
This site is protected by reCaptcha and the Google Privacy Policy and Terms of Service apply.