In zwei vorangehenden Artikeln zum Thema haben wir zuletzt besprochen, wie sich der Continuous-Delivery-Workflow im Rahmen des Branch-per-Issue-Vorgehens gestaltet. In Teil 1 wurde der Basisablauf vorgestellt, ehe wir in Teil 2 auf die Besonderheiten bei der Entwicklung von SaaS-Produkten auf der einen und installierten Produkten auf der anderen Seite eingegangen sind. Nun kommen wir zum CD-Workflow für Gitflow-Projekte.

Statt eines einzelnen master-Branchs sieht der Gitflow-Ansatz zwei Branches vor, in denen die Historie des Projekts festgehalten wird. Während der master-Branch Tags und/oder Commits enthält, die die offizielle History abbilden, gibt ein geteilter Integrations-Branch (häufig develop) unserem Team die Möglichkeit, Bugs und inkompatible Änderungen aufzuspüren.

Schritt 1: Branch erstellen

Auch hier ist der Unterschied zum Basis-Workflow die Frage, von wo aus wir branchen. Für neue Entwicklungsarbeit zweigen wir unseren Branch vom develop-Branch ab (wobei wir sicherstellen, dass wir von einem sauberen Commit aus branchen). Für Bugfixes, die eine bereits ausgelieferte Version betreffen, branchen wir von einem Branch mit einer stabilen Version.

(Mehr zum Gitflow-Workflow findet sich in dieser Einführung. Bitbucket unterstützt alle Variationen und zudem Branch-Berechtigungen, was uns in die Lage versetzt, den Zugriff auf master- oder Versions-Branches zu kontrollieren.)

Unabhängig davon, von wo aus wir branchen, sollten wir das Branch-Update-Feature von Bamboo nutzen, um mit jedem Build Änderungen aus dem Eltern-Branch in unseren Feature-Branch zu pullen. So können wir Integrationsprobleme früh aufdecken und sie beheben, statt sie erst dann zu finden, wenn wir sie mit in den develop-Branch gemergt und damit auch bereits verbreitet haben.

Mit dem Gitflow-Modell ist es möglich, vom master zu releasen oder von Branches mit stabilen Versionen. Als Faustregel gilt, unser Release zum Primär-Branch für unsere Bamboo-Builds zu machen – dies spielt eine Rolle, wenn es später Zeit zum Deployen ist – und Plan Branches zu aktivieren, damit alle Branches sorgfältig getestet werden.

Schritt 2: Coden, testen, wiederholen

Der Schritt des Testens ist beim Gitflow-Workflow sehr interessant. Wie in allen Continuous-Delivery-Workflows nutzen wir Plan Branches in Bamboo, um unseren Feature-Branch Tests zu unterziehen, aber der Unterschied liegt hierin: Wenn die Implementierung komplett ist und alle Test durchlaufen, mergen wir in den develop-Branch und nicht in den master.

Der develop-Branch können wir uns als den Schmelztigel vorstellen, in dem alle Änderungen unseres Teams zusammenkommen, und wir wollen Feedback von jedem Commit erhalten, um Debugging-Tests einfacher zu machen. Der beste Weg, dies zu gewährleisten, besteht darin, den develop-Branch so zu konfigurieren, dass Builds durch Push-Benachrichtigungen aus Bitbucket angestoßen werden. Das periodische Abfragen des Repos würde mitunter dazu führen, dass die Änderungen aus diversen Commits in einem einzelnen Build eingefangen werden, weil in den develop-Branch so häufig Änderungen eingehen. Das ist besser geeignet für Branches, die sich nicht ganz so häufig verändern.

Ein weiterer Vorteil der vom Repository angestoßenen Builds für den develop-Branch ist der, dass die CPU von Bamboo effizient genutzt wird (siehe unseren Beitrag über CI-freundliche Git-Repositories). Für Teams und Organisationen, die ständig auf großer Skala ausliefern, ist das wirklich ein Unterschied.

Wie beim Basis-Workflow sollten wir sicherstellen, dass wir den develop-Branch runter in unseren Feature-Branch mergen (oder rebasen) und noch ein letztes Mal Tests durchführen, bevor dieser wieder in develop eingeht.

Schritt 3: Mergen

Es ist Standard, einen Pull-Request zu erstellen, wenn wir unseren Feature-Branch in den develop-Branch mergen. Peer-Code-Reviews sind in diesem Stadium viel einfacher, als wenn wir sie hinauszögern, bis wir bereit zum Ausliefern sind. In diesem Fall müssten wir nämlich alle Änderungen seit dem letzten Release auf einen Schlag reviewen.

Wenn wir den Feature-Branch in den develop-Branch mergen, werden wir uns zwangsläufig mit fehlgeschlagenen Tests konfrontiert sehen. Statt Änderungen nun direkt im develop vorzunehmen, checken wir unseren Branch erneut aus und machen dort die Änderungen.

Schritt 4: Ausliefern

Den Release-Branch zum Primär-Branch unseres Build-Plans in Bamboo zu machen, macht uns fit für wirklich gradlinige Deployment-Projekte. Welcher Branch auch immer unser Primär-Branch für den Build-Plan ist – er wird automatisch der Primär-Branch für unsere Deployment-Jobs sein, und somit können wir das Deployment-Projekt so aufsetzen, dass es auch Builds von Feature-Branches deployt.

Wie beim SaaS-Workflow können wir basierend auf den erfolgreichen Builds von develop automatisch Tags für den master erstellen und direkt von diesen Tags deployen. Oder wir warten, bis sich im develop-Branch eine gewisse Zahl von Features gesammelt hat, und erstellen den Tag manuell. Es kommt einfach darauf an, ob wir uns weiter in Richtung Continuous Deployment bewegen oder es erstmal bei Continuous Delivery belassen möchten. Gitflow unterstützt beides.

Damit sind wir am Ende dieser dreiteilige Artikelreihe. Sie hat gezeigt, wie JIRA Software, Bitbucket und Bamboo zusammenspielen und das Branch-per-Issue-Modell im Rahmen des Continuous-Delivery-Konzepts unterstützen können. Für jedes Stück Arbeit einen Branch zu erstellen, führt dazu, dass wir uns nie mit anderen Teammitgliedern ins Gehege kommen und, was am wichtigsten ist, dass unsere kritischen Branches immer und zu jeder Zeit sauber und auslieferbar sind.

Wir sind Ihr Atlassian-Partner!

Sie möchten Atlassian-Tools neu einführen oder Lizenzen verlängern? Sie haben Fragen zu technischen oder organisatorischen Punkten? Als offizieller Atlassian-Vertriebspartner und einer der größten Atlassian Experts weltweit mit Erfahrungen aus Hunderten Atlassian-Projekten unterstützen wir Sie gerne bei allen Aspekten rund das gesamte Produktportfolio des australischen Software-Herstellers. Sprechen Sie uns einfach unverbindlich an.

Weiterführende Infos

99 Argumente für Bitbucket Server (Stash) als Git-Repository-Manager
Branch-basierte Git-Workflows adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
So funktioniert die Lizenzierung von Atlassian-Produkten