Die trunkbasierte Entwicklung ist eine von mehreren Branching-Strategien, die häufig in Verbindung mit Continuous Integration und Continuous Delivery/Deployment (CI/CD) verwendet werden.
Bei der trunkbasierten Entwicklung werden Änderungen direkt in den Master-Branch (auch Trunk genannt) übernommen, statt Features oder Fehlerkorrekturen in separaten Branches zu entwickeln und sie zu einem späteren Zeitpunkt mit dem Master zusammenzuführen.
Commits in den Master-Branch lösen die CI/CD-Pipeline aus. Wenn der Pipeline-Durchlauf Fehler ergibt, liegt es in der Verantwortung jedes Einzelnen, einzugreifen und das Problem so schnell wie möglich zu korrigieren. Das Ziel ist es, den Master-Branch in einem Deplyoment-bereiten Zustand zu halten und Änderungen häufig zu veröffentlichen.
Wenn Sie mit den Prinzipien von CI/CD bereits vertraut sind, haben Sie wahrscheinlich anhand der obigen Beschreibung erkannt, dass die trunkbasierte Entwicklung gut zu Continuous Integration und Deployment passt. Wenn alle Teammitglieder regelmäßige Commits vornehmen, erhalten Sie nicht nur einen Überblick über alle Änderungen, sondern auch regelmäßiges, schnelles Feedback zu Ihren Builds.
Die Notwendigkeit, den Master-Branch in einem guten, releasefähigen Zustand zu erhalten, veranlasst alle Mitwirkenden dazu, ihre Änderungen gleich mit Tests abzusichern. Durch Überwachung der Test-Coverage können Sie ein Auge auf diese Entwicklung haben. Indem Sie dafür sorgen, dass jeder vor einem Commit erst einen lokalen Buildvorgang (evtl. in Verbindung mit einer vereinfachten automatisierten Testreihe) ausführt, können Sie außerdem die Anzahl der Probleme, die erst im Master entdeckt werden, reduzieren.
Einige Befürworter der trunkbasierten Entwicklung halten sie für die einzige Methode, eine kontinuierliche Integration umzusetzen. Sie sind der Ansicht, dass die Verwendung von Entwicklungs- oder Feature-Branches die Vorteile von CI/CD untergräbt. Allerdings hat auch die trunkbasierte Entwicklung ihre Schattenseiten.
Das Modell passt zwar hervorragend zu Continuous Deployment, bei dem Codeänderungen, die alle Phasen der Pipeline durchlaufen haben, automatisch veröffentlicht werden. Dies eignet sich jedoch vor allem für SaaS-Produkte, bei denen kontinuierliche Updates in Kauf genommen oder sogar erwartet werden.
Wenn Ihr Produkt installiert oder als Mobil-App bereitgestellt wird, kann es hingegen sinnvoll sein, Änderungen zu regelmäßigen Releases zusammenzufassen, statt für jedes Update, das die Pipeline durchläuft, eine neue Version zu veröffentlichen.
In diesem Fall können Branches dazu beitragen, den Inhalt der einzelnen Releases zu verwalten und Support für mehrere Produktversionen gleichzeitig bereitzustellen.
Eine potenzielle Herausforderung bei der trunkbasierten Entwicklung besteht in der Handhabung großer oder komplexer Features. Bei regelmäßigen Commits an den Master in Verbindung mit der direkten Bereitstellung in der Produktionsumgebung benötigen Sie eine Möglichkeit, Features zu verwalten, die noch nicht für Ihre Benutzer*innen verfügbar sein sollen.
Feature-Flags bieten eine Möglichkeit, die Sichtbarkeit von Features bei der trunkbasierten Entwicklung zu steuern, aber ihre Verwaltung kann komplex sein. Eine Alternative besteht in der Verwendung von Feature-Branches, die Ihnen die Möglichkeit geben, Features separat zu halten, bis sie veröffentlichungsbereit sind.
Für Teams, die neu in CI/CD eingestiegen sind und noch nicht über eine robuste Testsuite verfügen, kann es schwierig sein, Änderungen direkt in den Master zu übernehmen und gleichzeitig die Deployment-Bereitschaft aufrechtzuerhalten. Wenn die trunkbasierte Entwicklung ansonsten gut zu Ihrer Arbeitsweise passt, könnten Sie sich ihre Einführung zum Ziel setzen, auf das Sie hinarbeiten können, während Sie Ihr CI/CD-Know-how ausbauen.
Die trunkbasierte Entwicklung passt gut zu Continuous Integration und Deployment und funktioniert dann am besten, wenn Sie über eine robuste automatisierte Testsuite verfügen, nicht mehrere Softwareversionen gleichzeitig unterstützen und Ihre Updates nicht zu Releases bündeln müssen. Sie ist jedoch keinesfalls die einzige Option, und je nach Ihrer Situation könnten andere Branching-Strategien besser zu Ihnen passen.