Branching-Strategie: auf dem Weg zum Erfolg

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.

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.

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.

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.

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.

Bei Atlassian setzen wir den Fokus auf einen "Branch-pro-Task"-Workflow. Jedes Unternehmen hat eine natürliche Methode, in einem Issue Tracker wie Jira Arbeit in einzelne Tasks aufzuteilen. Vorgänge werden bei diesem Teil der Arbeit dann zum zentralen Kontaktpunkt des Teams. Beim Task-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.

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!

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.