Rethinking Branching: Stabilität und Vorhersehbarkeit für Ihre Releases

Zu häufig werden Releases durch Bugs verzögert oder schlimmer noch, Bugs treten erst im produktiven Einsatz auf und erfordern eine weitere Runde von Release-Tests und Bereitstellungen. Dies kostet das Unternehmen Zeit, Geld und den guten Ruf, da Fristen verpasst werden und der gesamte Test- und Bereitstellungszyklus erneut gestartet werden muss. Dieses Branching-Modell wurde als Lösung hierfür entwickelt, da der Hauptfokus auf der Stabilität aktueller und bevorstehender Releases liegt. Dies ist besonders wichtig in Umgebungen, in denen sowohl Bereitstellungen als auch Tests für Releases kostspielig und zeitaufwändig sind, wie es häufig bei eingebetteten Systemen der Fall ist.

Ich habe oft mit Software-Entwicklungsteams gearbeitet und dabei den Satz gehört: „Wir verwenden Git Flow." Während dies zu Beginn vielleicht wahr war, können Druck und Erfahrungen auf verschiedenen Ebenen dazu führen, dass Organisationen dies allmählich in ihr eigenes System umwandeln. Ein solches System, das ich häufig antreffe, bezeichne ich als das „release-basiertes Branching-Modell".

In diesem Modell existiert kein kontinuierlicher Develop-Branch; stattdessen wird eine Reihe von aufeinander aufbauenden Release-Branches verwendet, die erstellt werden, sobald ein Feature für ein spezifisches Release geplant und in Entwicklung ist. Features werden dann in die Releases gemerged, und Releases werden sofort in später versionierte Releases zusammengeführt. Die frühzeitige Trennung der Release-Branches ermöglicht es, Features, Refactorings und Bugfixes (und damit potenzielle neue Bugs) voneinander zu isolieren. Statt Änderungen direkt in den Develop-Branch zu mergen, werden sie gezielt in zukünftige Releases eingeplant und in separate Branches integriert.

Die Nettoauswirkung dieser Strategie ist die allgemeine Erhöhung der Softwarequalität und Stabilität aufgrund der frühzeitigen Isolation geplanter Release-Branches. Dieser Effekt geht allerdings mit einem leichten Aufwand für die Entwickler:innen einher, aufgrund der grösseren Anzahl an Merges (und möglicherweise Merge-Konflikten), aber im Allgemeinen wird der Anstieg der Stabilität als lohnenswert angesehen.

Auf den ersten Blick könnte man meinen, dass der Hauptunterschied zwischen diesem Modell und Git Flow darin besteht, dass es keinen Develop-Branch gibt. Praktisch gesehen ist das jedoch nicht wahr: Es wird immer einen „höchsten" Release-Branch geben, und von einer bestimmten Perspektive aus betrachtet, ist dies einfach ein „Develop"-Branch, der kontinuierlich umbenannt wird.

Der wesentliche Unterschied bei diesem Branching-Modell liegt im Zeitpunkt, in dem neue Release-Branches erstellt werden. Während bei Git Flow eine Entscheidung getroffen wird, um „Develop zu stabilisieren", indem ein Release-Branch erstellt wird, konzentriert sich dieses Branching-Modell darauf, einen Release-Branch zu erstellen, sobald ein Feature für ein bestimmtes Release geplant ist. Dies ermöglicht es dem nächsten Release, nur spezifische geplante Features, Fixes oder Refactorings zu erhalten.

Release-Branches sollten so benannt werden, dass sie das allgemeine Release kennzeichnen (zum Beispiel release/20.x), und spezifische Releases sollten getaggt werden (zum Beispiel release/20.1.0). Im Versionierungsschema sollte Platz für Hotfixes gelassen werden, die dann von spezifischen Releases abzweigen und entsprechend getaggt werden können, bevor sie in das letzte aktive aktuelle Release zusammengeführt werden. Die Benennung von Hotfix-Branches kann einen eigenen Bezeichner haben (z. B. hotfix/20.1.0.1), aber in der Praxis ist die Benennung etwas weniger wichtig, da Hotfix-Branches (wie alle anderen Branches) nach dem Taggen als Release und dem Hochmerge in der Regel gelöscht werden sollten.

Die "Main"- oder "Master"-Branches sind ebenfalls nicht mehr notwendig. Manchmal ist es nützlich, für ein Projekt die aktuelle Version anzuzeigen. In diesem Fall kann die Main Branch verwendet werden und manuell auf spezifische getaggte Releases platziert werden, anstatt ein Release in ihn zu mergen. Dies hält alle Release-Hashes identisch, was wichtig ist.

Es ist vielleicht einfacher, dieses System anhand konkreter Beispiele zu verstehen, anstatt anhand abstrakter Beschreibungen.

In diesem Beispiel wäre der erste Schritt, einen bestehenden „Develop"-Branch so umzubenennen, dass er mit der nächsten bevorstehenden Release-Version übereinstimmt, sagen wir „release/4.5.x". An diesem Punkt erfolgt die Entwicklung wie gewohnt, und das Feature „A" wird in release/4.5.x gemerged.

Sobald ein neues Feature oder ein Bugfix für eine spätere Version geplant wird, sollte ein neuer Branch erstellt werden, zum Beispiel „release/4.6.x", mit geplanten Features „B" und „C", die von 4.5.x abzweigen.

Es ist wahrscheinlich, dass die Entwicklung auf 4.5.x weitergeht, sodass es zwei Beispiel-Bugfixes „D" und „E" erhält. Bugfix „D" wird zuerst in 4.5.x gemerged und dann wird der Branch release/4.5.x sofort in release/4.6.x zusammengeführt.

Anschliessend wird Bugfix „E" in 4.5.x gemerged. Dies vervollständigt die Version 4.5.x, sodass dieser Branch das Tag „release/4.5.0" erhält. In diesem Beispiel gibt es einen Konflikt zwischen 4.5.x (das gerade Bugfix „E" erhalten hat) und 4.6.x. Um dies zu lösen, wird ein Merge-Branch erstellt: „merge/4.5-4.6", aus release/4.6.x. Hier wird der Branch 4.5.x gemerged, Konflikte gelöst und dann der gesamte Branch zurück in 4.6.x gemerged, wo später auch das geplante Feature C gemerged wird.

Mit diesem Branching-System ist eine der besten Regeln, die zu befolgen sind: „so schnell wie möglich in die übergeordneten Branches mergen". Dies verhindert, dass kleinere Probleme sich zu grösseren entwickeln. Daher sollten diese Branches sofort nach dem Merge in einen niedrigeren Release-Branch nach oben gemerged werden. Idealerweise sollte ein automatisiertes System verwendet werden, um dies zu tun.

Planung ist ebenfalls ein Schlüsselelement dieses Systems, stösst jedoch häufig auf den Wunsch, neue Features früher bereitzustellen. In diesen Fällen besteht die einzige Option darin, Features, die in späteren Versionen gemerged wurden, selektiv zurück in neue Feature-Branches zu integrieren. Aus der Sicht von Git ist dies etwas unordentlich, sollte aber zumindest kein Problem darstellen, wenn der nachfolgende Aufwärts-Merge erfolgt.

Dieser Ansatz steht im Gegensatz zu verbreiteten modernen Branching-Strategien, die häufig einzelne Haupt-Branches für kontinuierliches Mergen und Bereitstellen bevorzugen. Dieses Modell ergibt sich jedoch als praktische Lösung für spezifische Einschränkungen. Häufig wird diese Methode von Entwickler:innen mit Widerstand begegnet, die hauptsächlich die erhöhten Kosten ihres Aufwands in Bezug auf Merging und das Lösen von Merge-Konflikten sehen. Wenn jedoch die gesamte organisatorische Perspektive betrachtet wird, machen die Gewinne in der Stabilität der Releases oft diese anfängliche Investition wett.

Haben Sie Fragen zu Branching-Strategien oder möchten Sie Ihre Entwicklungsprozesse optimieren? Unsere Expert:innen bei adesso unterstützen Sie gerne.