Branching-Strategie: auf dem Weg zum Erfolg

Oder finde deinen Weg durch Aufgaben-Branching. Oder Release Branching. Du entscheidest.

Dan Radigan Von Dan Radigan
Themen durchsuchen

Nahezu alle Versionskontrollsysteme unterstützen heute Branches, das heißt unabhängige Arbeitsgebiete, die aus einer zentralen Codebasis abgeleitet werden. Je nach Versionskontrollsystem heißt der Haupt-Branch Mainline, Default oder Trunk. Entwickler können eigene Branches aus dem Haupt-Branch erstellen und unabhängig an diesen arbeiten.

Was spricht dafür, die Mühe des Branchings auf sich zu nehmen?

Durch Branching können Entwicklerteams auf einfache Weise innerhalb einer zentralen Codebasis zusammenarbeiten. Erstellt ein Entwickler einen Branch, erstellt das Versionskontrollsystem eine Kopie der Codebasis zu diesem Zeitpunkt. Änderungen am Branch wirken sich nicht auf andere Entwickler im Team aus. Und das ist auch gut so, weil Features, die sich noch in der Entwicklung befinden, Instabilität erzeugen können. Es würde die Arbeit des Teams stören, wenn die gesamte Arbeit im Haupt-Branch stattfinden würde. Aber Branches müssen nicht isoliert sein. Entwickler können auch einfache Änderungen von anderen Entwicklern einarbeiten, an Features zusammenarbeiten und sicherstellen, dass ihr eigener Branch nicht zu weit vom Haupt-Branch abweicht.

Profitipp

Branches sind nicht nur für die Arbeit an Features geeignet. Branches können das Team von umfassenden architekturbezogenen Änderungen wie das Aktualisieren von Frameworks oder gemeinsamen Bibliotheken usw. isolieren.

Drei Branching-Strategien für agile Teams

Branching-Modelle werden in Teams oft unterschiedlich umgesetzt und sind Thema zahlreicher Debatten in der Software-Community. Eins der vorrangigen Themen ist, wie viel Arbeit in einem Branch verbleiben sollte, bevor er zurück in den Haupt-Branch gemergt wird.

Release Branching

Das Release-Branching basiert auf der Idee, dass sich ein Release komplett innerhalb eines Branch befindet. Das heißt, dass der Release-Manager zu einem späten Zeitpunkt im Entwicklungszyklus einen Branch aus dem Haupt-Branch erstellt (z. B. "Entwicklungs-Branch 1.1"). Alle Änderungen für das Release 1.1 müssen zweimal angewendet werden: einmal für den Branch 1.1 und das zweite Mal für die Hauptcodezeile. Das Arbeiten mit zwei Branches bedeutet zusätzlichen Aufwand für das Team, bei dem das Mergen an beiden Branches schnell vergessen wird. Release-Branches können unhandlich und schwer zu verwalten sein, weil viele Personen am selben Branch arbeiten. Wir hatten alle schon Probleme damit, viele verschiedene Änderungen an einem einzigen Branch zu mergen. Wenn ein Release-Branch erforderlich ist, erstelle den Branch möglichst zeitnah zum tatsächlichen Release.

Warnung:

Warnung: Das Release-Branching ist für den Support versionierter Software auf dem Markt sehr wichtig. Ein einziges Produkt verfügt möglicherweise über mehrere Release-Branches (z. B. 1.1, 1.2, 2.0), um eine nachhaltige Entwicklung zu unterstützen. Denke daran, dass Änderungen in frühen Versionen (z. B. 1.1) möglicherweise in spätere Release-Branches (z. . 1.2, 2.0) gemergt werden müssen. Weitere Informationen zum Verwalten von Release-Branches mit Git erhältst du im unten erwähnten Webinar.

Feature Branching

Feature-Branches werden oft mit Feature-Flags kombiniert – eine Art "Umschalter", mit denen ein Feature im Produkt aktiviert oder deaktiviert werden kann. Damit kann der Code einfacher im Haupt-Branch bereitgestellt werden, und es ist einfacher zu steuern, wann das Feature aktiviert wird. So lässt sich der Code weit vor dem Zeitpunkt bereitstellen, zu dem das Feature für Endbenutzer zur Verfügung gestellt wird.

Profitipp:

Ein weiterer Vorteil von Feature Flags besteht darin, dass der Code zwar im Build verbleibt, aber inaktiv ist, solange er sich in der Entwicklung befindet. Wenn bei der Aktivierung des Codes etwas schiefgeht, kann ein Systemadministrator das Feature Flag rückgängig machen und zu einem bekannten funktionierenden Status zurückkehren, statt einen neuen Build bereitstellen zu müssen.

Aufgaben-Branching

Bei Atlassian setzen wir den Fokus auf einen "Branch-pro-Aufgabe"-Workflow. Jedes Unternehmen hat eine natürliche Methode, in einem Vorgangs-Tracker wie Jira Software Arbeit in einzelne Aufgaben aufzuteilen. Vorgänge werden bei diesem Teil der Arbeit dann zum zentralen Kontaktpunkt des Teams. Beim Aufgaben-Branching, auch Vorgangs-Branching genannt, werden diese Vorgänge direkt mit dem Quellcode verbunden. Jeder Vorgang wird in seinem eigenen Branch implementiert und der Vorgangsschlüssel ist in den Branch-Namen integriert. Es ist leicht zu sehen, welcher Code welchen Vorgang implementiert: Du musst nur nach dem Vorgangsschlüssel im Branch-Namen suchen. Durch diese Transparenz ist es einfacher, bestimmte Änderungen am Haupt-Branch oder an einem beliebigen älteren Release-Branch vorzunehmen.

Da Agile auf User Storys aufbaut, passen Task-Branches gut zur Agile-Entwicklung. Jede User Story (bzw. jeder Bugfix) bleibt in einem eigenen Branch, damit leicht ersichtlich ist, welche Vorgänge noch bearbeitet werden und welche zum Release bereit sind.

Kommen wir zum bösen Zwillingsbruder des Branchings: dem Mergen

Wir haben alle schon verzweifelt versucht, mehrere Branches in eine vernünftige Lösung zu integrieren. Früher haben zentralisierte Versionskontrollsysteme wie Subversion das Mergen zu einem sehr aufwändigen Vorhaben gemacht. Aber neuere Versionskontrollsysteme wie Git und Mercurial basieren auf einem anderen Ansatz für die Nachverfolgung von Datenversionen, die in verschiedenen Branches existieren.

Branches sind oft kurzlebig, damit sie einfacher zu mergen sind und über die Codebasis hinweg flexibler bleiben. Da Branches als Teil von Continuous Integration (CI) oft und automatisch gemergt werden können und kurzlebige Branches schlicht und einfach weniger Änderungen enthalten, gehört die "Merge-Hölle" für Teams, die Git und Mercurial verwenden, mittlerweile der Vergangenheit an.

Darum ist das Task-Branching so fantastisch!

Prüfen, prüfen, prüfen

Ein Versionskontrollsystem kann das Ergebnis eines Merge-Vorgangs nur begrenzt beeinflussen. Auch automatisierte Tests und Continuous Integration sind wichtig. Mit den meisten CI-Servern können neue Branches automatisch getestet werden, was die Anzahl der "Überraschungen" beim letzten Upstream-Merge deutlich reduziert und dazu beiträgt, den Haupt-Branch stabil zu halten.