Feature Branching für großartige Ergebnisse

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

Dan Radigan Dan Radigan

Nahezu alle Versionskontrollsysteme unterstützen heute Branches – unabhängige Arbeitsgebiete, die aus einer zentralen Codebasis abgeleitet werden. Je nach Versionskontrollsystem heißt der Haupt-Branch Master, 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. Wenn ein Entwickler einen Branch erstellt, 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 in der 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 Master 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 einzelnen 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 Master gemergt wird. 

Release Branching

Das Release Branching basiert auf der Idee, das sich ein Release komplett innerhalb eines Branchs befindet. Das heißt, dass der Release-Manager zu einem späten Zeitpunkt im Entwicklungszyklus einen Branch aus dem Master 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 Master-Codezeile. Das Arbeiten mit zwei Branches bedeutet einen 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. 

Warning:

Release branching is an important part of supporting versioned software out in the market. A single product may have several release branches (e.g., 1.1, 1.2, 2.0) to support sustaining development. Keep in mind that changes in earlier versions (i.e., 1.1) may need to be merged to later release branches (i.e., 1.2, 2.0). Check out our webinar below to learn more about managing release branches with Git.

Feature Branching

Feature Branches werden oft mit Feature Toggles kombiniert – eine Art "Umschalter", mit denen ein Feature im Produkt aktiviert oder deaktiviert werden kann. Damit kann der Code einfacher im Master bereitgestellt und es kann einfacher gesteuert werden, wann das Feature aktiviert wird. Auf diese Weise kann der Code weit vor dem Zeitpunkt bereitgestellt werden, zu dem das Feature für Endbenutzer zur Verfügung gestellt wird. 

Profitipp:

Another benefit of feature flags is that the code can remain within the build but inactive while it's in development. If something goes awry when the feature is enabled, a system admin can revert the feature flag and get back to a known good state rather than have to deploy a new build.

Aufgaben-Branching

At Atlassian, we focus on a branch-per-task workflow. Every organization has a natural way to break down work in individual tasks inside of an issue tracker, like Jira Software. Issues then becomes the team's central point of contact for that piece of work. Task branching, also known as issue branching, directly connects those issues with the source code. Each issue is implemented on its own branch with the issue key included in the branch name. It’s easy to see which code implements which issue: just look for the issue key in the branch name. With that level of transparency, it's easier to apply specific changes to master or any longer running legacy release branch.

Da agile Methoden auf User Storys aufbauen, passen Aufgaben-Branches gut mit der agilen Entwicklung zusammen. Jede User Story (oder Bug-Korrektur) bleibt in einem eigenen Branch, damit leicht ersichtlich ist, welche Vorgänge noch bearbeitet werden und welche für das Release bereit sind. Für einen umfassenden Einblick in das Aufgaben-Branching (das auch als Vorgangs-Branching oder Branch-pro-Vorgang bezeichnet wird) schnapp dir etwas Popcorn und schau dir die unten aufgeführte Webinar-Aufzeichnung an – die zu unseren beliebtesten überhaupt zählt. 

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 Aufgaben-Branching so fantastisch! 

Prüfen, prüfen, prüfen

A version control system can only go so far in affecting the outcome of a merge. Automated testing and continuous integration are critical as well. Most CI servers can automatically put new branches under test, drastically reducing the number of "surprises" upon the final merge upstream and helping to keep the main code line stable.