Der erste Teil dieser Artikelserie lieferte einen ersten Überblick zu Git Essentials. Im zweiten Teil befassen wir uns mit der Frage, wie Git Essentials den Arbeitsalltag von Entwicklern mit Bamboo und Stash erleichtern kann.

Pull Requests & Code Reviews

Entwickelt man nach einem Workflow-Modell, ob einfache Prinzipien wie Feature-Branching oder komplexe Workflows wie Gitflow – in Atlassian Stash lassen sich die gängigsten Modelle abbilden, so dass Git reibungslos adaptiert werden kann. Für einen Überblick zu Git Workflows und deren Umsetzung lohnt sich ein Blick auf unsere Artikelserie zu Git Workflows

Nehmen wir also an, die Entwicklung eines Features in einem isolierten Feature-Zweig ist abgeschlossen, alle Vorgänge in JIRA sind dank Workflow-Triggern auf dem neusten Stand und sollen nun integriert werden. Ein Git Workflow verlangt unter Umständen, dass Änderungen einem Review unterzogen werden.

Stash bietet mit Pull Requests einen Mechanismus, um Code Reviews in den Entwicklungsablauf einzubauen. Ein Entwickler stellt eine Art Anfrage, Änderungen an einem Zweig in einen anderen zu integrieren.

Pull_request_code_review

Pflichtmäßiges Feedback von Kollegen für Codeänderungen lässt sich vorschalten, sobald Änderungen reif für den Haupt-Entwicklungszweig sind. Codeänderungen, Issues, Build-Ergebnisse und Review-Kommentare werden an einem Ort vereint, somit hat das Team ein komplettes Dashboard zur Evaluation der Qualität des Codes zur Verfügung.

ge-stash

Die Workflow Trigger aus JIRA greifen auch hier. Möchte ein Entwickler seinen Feature-Zweig in den Hauptzweig integrieren, so öffnet er einen Pull Request. Der Pull Request Created-Trigger löst hier automatisch einen Übergang nach In Review aus. Wird der Pull Request abgelehnt, helfen die entsprechenden Trigger, den Vorgang wieder in den vorigen Zustand zu überführen – und so weiter.

stash-pull-request-reviewers

Sehr nützlich sind die Bedingungen, wie z.B. eine minimale Anzahl an erfolgten Reviews. Zusätzliche Sicherheit bietet die Option, einen erfolgreichen Bamboo-Build als Voraussetzung für die Integration des Features in einen Zweig zu setzen.

Builds & Merges mit Bamboo

Eines der Hauptmotive von Branching-Modellen und der Entwicklung von Funktionen bzw. Abarbeitung von Vorgängen in isolierten Feature-Branches ist die Aufrechterhaltung eines stabilen Zustandes eines als Hauptzweig markierten Branches, um diesen in einem potenziell auslieferbaren Zustand zu halten. Um die Vorteile eines Branching-Modells wie Gitflow mit Hauptzweigen und temporären Zweigen voll ausschöpfen zu können, müssen alle Zweige – auch die temporären – von einem Continuous Integration-Server übersetzt werden. Der Gedanke an die Verwaltung von vielen kurzlebigen Zweigen in einem Continuous Integration-System führt bei so manchem versierten IT-Administrator oder Entwickler unweigerlich zu Schweißausbrüchen. In der Vergangenheit bedeutete jeder zusätzliche Zweig einen zeitlichen und verwaltungstechnischen Mehraufwand; meist waren Freigaben über mehrere Ebenen hinweg und Personen in unterschiedlichen Rollen involviert. Manchmal dauert das Erstellen bzw. das Einhängen und anschließende Entfernen eines Zweiges aus dem Buildprozess länger als die eigentliche Lebensdauer desselbigen in der Entwicklung.

Die Befürchtung neben einer Merge-Hell auch noch in einer CI-Configuration Hell voller Altlasten zu landen, ist nicht weit hergeholt. Dank automatischer Zweig-Erkennung durch Branch Aware Builds detektiert Bamboo neu angelegte Feature-Zweige im Git-Versionskontrollsystem und legt eine Kopie des Buildplans für den Hauptzweig während der Lebensdauer eines solchen Zweiges an.

Bamboo Branch Updating: Feature-Zweige aktuell halten

Bamboo kann nicht nur nur Zweige erkennen und nahtlos einhängen, sondern auch automatische Merges durchführen. Das Konzept des Branch Updatings kann zur Vermeidung einer späteren Merge-Hell durch zu große Unterschiede zwischen Haupt- und Nebenzweigen beitragen, indem diese miteinander synchronisiert werden.

branchupdate

Zweige werden stets aktuell gehalten, indem nach einem Commit und erfolgtem Build eines Hauptzweiges (z.B. Master) die Änderungen in alle existierenden Feature-Zweige übernommen werden. Hierdurch lassen sich die negativen Auswirkungen der isolierten Feature-Entwicklung minimieren, die sinnbildlich für große Divergenzen und anschließende Aufwände im Zusammenführen von Zweigen steht.

Stash Automatic Merging: Mehrere Releases synchron halten

Neben dem Branch Updating-Mechanismus von Bamboo verfügt Stash über die Funktionalität des automatischen Mergings von Release-Zweigen. Unterstützt man mehrere Software-Versionen gleichzeitig, z.B. die Versionen 1.0, 1.1 und 1.2 für bestimmte Kunden für weitere zwei Jahre obwohl bereits Version 2.0 veröffentlicht wurde, ist diese Funktion Gold wert. Ein Hotfix oder Feature kann somit ohne Mehraufwand in mehreren Versionen gleichzeitig veröffentlicht werden. Sofern für ein Stash-Repository aktiviert, kann dies unter zwei Voraussetzungen vollautomatisch stattfinden:

  • Nur Zweige, die einem bestimmten Muster entsprechen und fortfolgend versioniert wurden, werden aktualisiert.
  • Simple Commits lösen die Automatik nicht aus – ein Pull Request ist nötig.

Im folgenden Beispiel wurde ein Hotfix für die bereits veröffentlichte Version 1.1 fertiggestellt, welches automatisch in Release 1.2 übernommen wird – nicht aber in Version 1.0, da Stash erkennt, dass nur Veröffentlichungen ab Version 1.1 aktualisiert werden sollen.

Stash-AutoMerge21

Die Implikationen sind klar und der Traum eines jeden Entwicklers. Sind Stash und Bamboo verknüpft und Änderungen werden direkt übernommen, so können theoretisch mit nur einem Commit mehrere Releases erstellt und gebaut oder gar deployt werden.

Going Full Circle: Automatische Deployments

Zu guter Letzt bleibt noch der „Deploy“-Baustein unseres eingangs gezeigten Zyklus von „Concept to Launch“. Seit Version 5 verfügt Bamboo neben Build Plans auch über Deployment-Projekte.

Während Build Plans direktes Feedback liefern, ob ein Repository bzw. Zweig korrekt übersetzt und Artefakte produzieren, schließen Deployment-Projekte die Lücke zwischen erfolgreich produziertem Artefakt und dessen Veröffentlichung in eine bestimmte Umgebung. Dieser Teil ist vor allem für den IT-Betrieb von Relevanz und ist ein logisch von den Build-Plänen getrenntes Konzept in Bamboo.

Aufbauend auf den Resultaten eines erfolgreichen Builds in Bamboo und dessen Artefakten, z.B. einem Webanwendungsarchiv, können mithilfe von Deployment-Projekten diese in Releases gebündelt werden. Releases umfassen in der Regel mehrere Builds und Informationen wie zugehörige Commits und JIRA Issues und eine Historie, in welchen Umgebungen es wann deployt war.

BambooDeploymentProjects.png

Durch die Bündelung von Informationen unter einem Release lassen sich somit noch mehr Daten dank des Dev-Panels in JIRA direkt an dem Vorgang bereitstellen.

Das Dev-Panel als Schaltzentrale

Mithilfe des Dev-Panels behalten alle Beteiligten direkt am Issue in JIRA den Überblick über den Entwicklungsfortschritt dieses Vorgangs in der Atlassian-Werkzeuglandschaft. Es sammelt und vereint Informationen und Daten aus Stash und Build- sowie Deployment-Informationen von Bamboo.

Fragen von Stakeholdern können direkt beantwortet werden:

  • In welchen Zweigen befindet sich der Code?
  • Anzahl der Commits und auf Wunsch deren Details
  • Anzahl Pull-Requests: Wurde der Code bereits geprüft?
  • Anzahl Builds und Build-Status: Übersetzt der Code ordnungsgemäß?
  • Anzahl Deployments / Umgebungen: Wo läuft der Code zu dieser User Story / diesem Feature gerade?

jira-issue-devpanel.png

Durch diese Konsolidierung von Informationen müssen Projektbeteiligte tatsächlich zu keiner Zeit den gewohnten Kontext von JIRA verlassen – es sei denn Detailinformationen sind gewünscht.

Zusammenfassung

Mit Git Essentials vom Konzept bis zur Auslieferung? Atlassian scheint nicht übertrieben zu haben und demonstriert auf eindrucksvolle Art und Weise, wie die Integration von Werkzeugen für die Softwareentwicklung funktionieren kann. JIRA und JIRA Agile bilden das Rückgrat für Planung und Konzeption von Software und deren Funktionen; JIRA agiert als Schaltzentrale für die fachlichen Anwender und liefert alle relevanten Informationen direkt am Issue.

Entwickler können sich ganz auf ihre Aufgabe – das Entwickeln von Software – konzentrieren und müssen sich nicht um manuelle Zweig-Erstellung oder alltägliche Merges kümmern. Stash liefert mit der eingebauten Funktionalität für Pull Requests ein probates Mittel für leichtgewichtige Code-Reviews und entsprechende Freigaben zur Vorbereitung von Veröffentlichungen. Die Umsetzung von eigenen Workflow-Modellen ist ebenfalls möglich. Ebenso kann dank Workflow-Triggern ein Vorgang in andere Zustände überführt werden, ohne dass der Entwickler daran denken muss, um so alle Beteiligten automatisch auf dem neusten Stand zu halten. Bamboo besticht durch seine Deployment-Projekte und die Entlastung für den IT-Betrieb, indem Veröffentlichungen einfacher geplant und durchgeführt werden können.

ge_betrieb

Kleinere Einschränkungen, wie strikte Vorgaben für automatische Merges oder beschränkte Auswahl bei Workflow-Modellen, sind in der Praxis eigentlich kein Problem, können aber für besonders ausgefallene Workflow-Modelle zum Ausschlusskriterium werden. Einige nötige Anpassungen für automatische JIRA Workflow-Transitionen sind derzeit noch Mehraufwand und auch nicht ganz ausgereift. Dennoch liefert Atlassian ein stimmiges Gesamtpaket ab, das sich auch im alltäglichen Betrieb zu bewähren weiß.

In Verbindung mit Atlassian Agile Ready lässt sich Git Essentials zusätzlich um Confluence und Confluence Team Calendars ergänzen und die Umgebung deckt mit Werkzeugen zur Planung und gemeinsamen Erfassung von Wissen noch mehr Aufgabenbereiche ab.

Falls Ihr Interesse geweckt sein sollte, finden Sie auf unseren Seiten zu Git Essentials weitere Informationen zur Solution und wie OIO Braintime Ihnen behilflich sein kann.