Wie in unseren Artikeln zu CD-freundlichen Git-Repositories besprochen, ist umfangreiches Branching im Continuous-Delivery-Workflow eine gute Sache. Es hilft uns, unsere wichtigsten Branches sauber und auslieferbar zu halten, erlaubt Entwicklern, neue Dinge auszuprobieren, ohne ihren Teamkollegen auf die Füße zu treten, und macht das Projekt-Tracking einfacher.

Ein Branch-per-Issue-Workflow lässt sich exzellent in die Systemlandschaft von Atlassian-Tools integrieren und wird so zu einer mächtigen und zudem einfachen Praxis.

Der Branch-per-Issue-Workflow

Der Name sagt es bereits: Für jedes Stück Arbeit, also jeden Vorgang oder auch jede einzelne Code-Änderung, wird ein Entwicklungs-Branch erstellt – und mit JIRA Software ist das auch lückenlos und einfach nachvollziehbar. Dann erfolgt die ganze Implementierungs- und Testarbeit am Branch. Wenn wir fertig sind, setzen wir einen Pull-Request ab, mergen und releasen.

Sehen wir uns diesen Prozess mit Unterstützung von Atlassian-Tools Schritt für Schritt an.

Schritt 0: Die Tools integrieren

JIRA Software, Bitbucket und Bamboo lassen sich tief miteinander verzahnen. (Hier gibt es eine ausführliche Einführung zu den Integrationsmöglichkeiten.) Wir können sogar Cloud- und Server-Optionen mixen, sodass ein Team beispielsweise problemlos mit einer Systemlandschaft aus JIRA Software Server, Bamboo Server und Bitbucket Cloud arbeiten kann.

Auf die offensichtlichen Vorbereitungen wie das Erstellen von JIRA-Vorgängen, um die Arbeit zu tracken, das Aufsetzen eines Repos und das Konfigurieren von Builds und Deployment-Jobs wollen wir an dieser Stelle nicht weiter eingehen, sondern uns gleich in die Entwicklung stürzen.

Schritt 1: Branch erstellen

Wir öffnen den Vorgang in JIRA Software, weisen ihn uns selbst zu und ändern den Status auf "In Bearbeitung", sodass unser Team im Bilde ist. Dann wenden wir uns dem Entwicklungs-Panel rechts im Vorgang zu: Hier können wir aus JIRA heraus einen Branch erzeugen. Wenn mehr als ein Repository-Manager verknüpft ist, erscheint ein Screen, der uns fragt, mit welchem wir den Branch managen möchten. Andernfalls werden wir direkt zu einem Dialog weitergeleitet, in dem wir den Branch konfigurieren können.

Wir sehen, dass Bitbucket den Vorgangsschlüssel übernommen hat und ihn als Teil des Branch-Namens verwendet (in diesem Fall MKT-15886). Das ist die Voraussetzung für die Kommunikation zwischen den Systemen, insbesondere das Senden von Commits, Builds, Pull-Requests und Deployment-Informationen zurück zum Entwicklungs-Panel. Vorgangsschlüssel triggern alle Arten von Verknüpfungen und Automatisierungen über den CD-Workflow hinweg an, also sollten wir auf jeden Fall sicherstellen, dass sie in unseren Branches enthalten sind, ob wir nun über eine Oberfläche oder in der Kommandozeile arbeiten.

Im Dialog sehen wir auch Dropdown-Menüs, über die wir ein Präfix festlegen können, das den Zweck des Branchs indiziert (z.B. Bugfix, Feature, Release). Hier können wir darüber hinaus den Eltern-Branch oder Tag wählen, von dem aus unser neuer Branch erstellt werden soll. Nehmen wir an, dass unser gewählter Branch von Bamboo gebaut und getestet wird. Dann sehen wir einen Indikator, ob der Branch im Moment sauber ist. Das sollten wir im Auge behalten: Das Letzte, was wir brauchen, ist ein schöner neuer Branch, mit dem bereits irgendwo etwas nicht stimmt.

Haben wir alles nach unseren Wünschen konfiguriert, klicken wir auf den Button zum Erstellen des Branchs und Bitbucket kümmert sich um den Rest.

Schritt 2: Coden, testen, wiederholen

Dieser Teil ist uns natürlich vertraut: Wir klonen das Repo lokal, checken unseren neuen Branch aus und beginnen zu coden. Wenn wir schließlich in den neuen Branch pushen, hat Bamboo ihn im Repo bereits erkannt und Continuous Integration für ihn konfiguriert. Bamboo kontrolliert das Repo im Hinblick auf neue Branches und wendet die Builds auf sie an, die wir für den master konfiguriert haben.

Es ist empfehlenswert, in Bamboo automatisches Merging zu aktivieren. Am Anfang eines jeden Builds kann Bamboo je zwei beliebige Branches auschecken, sie mergen und dann den Build gegen den gemergten Code ausführen. In diesem Stadium des CD-Workflows mergen wir also Änderungen vom master in unseren Feature-Branch. Dadurch driftet unser Branch nicht weit vom master ab, und wir erhalten frühes Feedback, ob unsere Änderungen gut mit den Änderungen im master zusammenspielen.

Falls automatisches Mergen nicht so recht unser Fall ist, sollten wir definitiv den master in unseren Branch mergen (oder rebasen) und einen Build abschicken, um sicherzustellen, dass es keine unschönen Überraschungen gibt bzw. diese direkt repariert werden können. Wenn die Implementierung komplett ist und alle Tests durchlaufen, folgt der nächste Schritt.

Schritt 3: Mergen

Gewissenhaft, wie wir sind, mergen wir natürlich nicht in den master (oder in einen anderen wichtigen Branch), ohne einen Pull-Request abzusetzen. Am besten eignet sich dafür die Oberfläche von Bitbucket. Hier haben wir die Möglichkeit, die Diffs unseres Branchs und des Ziel-Branchs einzusehen. Dabei fallen oft schon ein, zwei Dinge auf, die wir direkt nachbessern können. Von diesem Vergleichsbildschirm aus klicken wir dann nur noch auf den Button zum Erstellen eines Pull-Requests und wählen die Reviewer.

Bitbucket ist wirklich mächtig, wenn es um Pull-Requests geht. Neben Side-by-Side-Diffs und Inline-Kommentaren gibt es auch die Möglichkeit, Regeln festzulegen, beispielsweise, dass Pull-Requests nur gemergt werden können, wenn mindestens zwei Leute sie freigegeben haben. Wir können auch Gatekeeper zwischenschalten, also Personen, die allein berechtigt sind, Merges in einen bestimmten Ziel-Branch durchzuführen.

Beim master-Branch (bzw. dem Branch, von dem aus wir releasen) sollten wir auf jeden Fall direkt nach jedem Push Builds durchführen. Dafür können wir in Bamboo automatische Build-Trigger konfigurieren.

Schritt 4: Ausliefern

Sobald der Build in unserem Release-Branch grün ist, sind wir potenziell bereit zur Auslieferung - potenziell deshalb, weil es natürlich auf unser Team ankommt, ob wir direkt ausliefern oder nicht: Sind alle Akzeptanzkriterien erfüllt? Haben die Artefakte angemessene Lasttests durchlaufen?

Wir können natürlich Bamboo zum automatischen Deployen des Builds nutzen, wenn wir Continuous Deployment vollumfänglich anwenden. Aber das ist nicht für jedes Team und jedes Produkt der geeignete Weg. Warum, sehen wir uns in demnächst erscheinenden Folgeartikeln an.

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