Definition „Trunk-basierte Entwicklung“ Was ist Trunk-based Development?
Anbieter zum Thema
Trunk-based Development, kurz TBD, ist in der Softwareentwicklung eine Vorgehensweise aus dem Versionsmanagement, bei der alle Codeänderungen einen gemeinsamen Hauptzweig eingecheckt werden. Dieser bildet die Arbeitsgrundlage für alle Entwicklerinnen und Entwickler.

Damit moderne Softwareentwicklung in einem Team auch bei komplexen Projekten geordnet funktionieren kann, muss Versionsmanagement betrieben werden. So werden alle Änderungen an einem Projekt fortlaufend dokumentiert und man kann nachvollziehen, wer wann was zur Software beigetragen hat.
Trunk-based Development (TBD) ist eine von vielen Methoden, um das Versionsmanagement umzusetzen. Die Besonderheit bei dieser Methode ist, dass der Fokus auf einem Hauptzweig (Trunk) liegt, der permanent in einem produktionsreifen Zustand gehalten werden soll.
Wie funktioniert Trunk-based Development?
TBD wird meistens mit Continuous Integration und Continuous Deployment kombiniert. So bleibt der Trunk stabil und kann schneller in den produktiven Betrieb überführt werden. Die Arbeit mit TBD läuft in etwa ab wie folgt.
- 1. Die aktuelle Version des Trunks wird ausgecheckt.
- 2. Die Arbeit findet auf einem persönlichen Branch statt. Änderungen können lokal entwickelt und getestet werden.
- 3. Die Änderungen werden so klein wie möglich gehalten, soweit die Komplexität des Projekts das erlaubt.
- 4. Die Änderungen werden auf fachliche Aspekte und auf Kompatibilität mit dem bestehenden Trunk getestet.
- 5. Die kontinuierliche Qualitätsprüfung stellt sicher, dass der Trunk trotz vieler kleiner Änderungen immer in einem releasefähigen Zustand ist.
- 6. Nach bestandener Prüfung werden sie auf den Hauptzweig eingecheckt.
- 7. Fehlerfall: Finden die Tests einen Fehler, wird sofort daran gearbeitet, diesen zu beheben, um das oberste Ziel der Integrität zu erfüllen.
- 8. Sobald der Hauptzweig fehlerfrei und stabil ist, wird die neueste Änderung direkt veröffentlicht, meist mittels eines Tools für Continuous Deployment.
Vorteile und Nachteile von Trunk-based Development
Wie bei jeder Vorgehensweise gibt es auch bei TBD bestimmte Stärken und Schwächen, die Teams vor dem Einsatz abwägen sollten.
Vorteile
- keine langen Wartezeiten oder gar Code Freezes beim Mergen
- geringe Anzahl an Konflikten beim Mergen
- Hauptzweig ist jederzeit releasefähig
Nachteile
- Ohne eine gute Testabdeckung inklusive gut konzipierter automatisierter Tests wird die Stabilität des Hauptzweigs gefährdet.
- Bei unsauberer Arbeitsweise kann es schneller zu Problemen kommen.
Für welche Projekte eignet sich Trunk-based Development?
Heute gibt es viele unterschiedliche Wege, um Versionsmanagement in einem Projekt zu realisieren. Welche Methode man wählt, muss an den Anforderungen und Eigenschaften eines Projektes festgemacht werden. Auch Aspekte wie die Größe und Struktur des Teams, die Qualitätsansprüche oder der zeitliche Rahmen des Projekts haben Einfluss darauf. TBD ist vor allem für Projekte sinnvoll, bei denen Folgendes zutrifft.
Hohe Agilität und Entwicklungsgeschwindigkeit: Änderungen werden bewusst klein gehalten und können schnell in den Hauptzweig integriert werden.
Hoher Qualitätsanspruch: Der Hauptzweig muss bei TBD dauerhaft in einem releasefähigen Zustand gehalten werden. Das setzt voraus, dass Qualität und Integrität des Codes hoch priorisiert werden.
Gewissenhafte Testabdeckung: Die Stabilität des Trunks wird durch flächendeckende Tests permanent gesichert.
Eher kleineres Team: Aufgrund der kleinmaschigen Arbeitsweise ist eine gute Kommunikation wichtig. Das gelingt am besten in kleineren Teams. Auch entstehen so weniger Konflikte beim Mergen.
Es gibt auch Situationen, in denen TBD ungeeignet ist, z. B. wenn das Projekt folgende Eigenschaften hat: eine hohe Komplexität, eine lange Entwicklungszeit, eine große Anzahl an Features und/oder eine große Anzahl an Entwicklern. Diese Eigenschaften haben gemeinsam, dass sie in der Regel sehr häufige Änderungen am Trunk erfordern. Das kann die Integrität des Hauptzweigs gefährden und das Mergen erschweren. In solchen Fällen bieten sich andere Arten des Versionsmanagements an.
Unterschiede zu anderen Arten des Versionsmanagements
Unterschiede von TBD zu anderen Praktiken:
Kein Feature Toggling
Hierbei können Änderungen ausgeliefert und mit einem Softwareschalter ein- oder ausgestellt werden. So lassen sich Änderungen unter realistischen Bedingungen testen, bevor Benutzer Zugriff darauf bekommen. TBD erlaubt diese Vorgehensweise nicht, da alle Änderungen auf dem Trunk bereit für den porduktiven Einsatz sein sollen.
Hauptzweig statt Branches
Einige Methoden arbeiten mit mehreren Branches und erlauben teils sogar jedem Entwickler seinen eigenen Branch. So kann länger und unabhängiger an einem Branch gearbeitet werden. Allerdings erschwert das auch das Mergen der Änderungen. Der Fokus auf den Trunk beim TBD kann solche Konflikte auf ein Minimum reduzieren.
Kein Feature Branching
Beim Feature Branching werden eigene Branches eröffnet, damit ein Entwickler oder ein Team in Ruhe bis zur Vollendung an einem Feature arbeiten kann. Dann kommt der Zeitpunkt, zu dem die umfangreichen Änderungen wieder mit dem übrigen Code zusammengeführt werden müssen.
Häufig wird dabei ein Code Freeze beschlossen, bis die komplexen Merges erfolgreich verarbeitet werden konnten. Feature Branching kann also dazu führen, dass die Entwicklung für eine gewisse Zeit ruhen muss, damit die Zusammenführung der einzelnen Branches funktioniert. TBD verzichtet darauf und benötigt deshalb keine langwierigen Code Freezes.
(ID:49025936)