Git Workflows Tutorial 3: Workflows in der Praxis

In den bisherigen Beiträgen wurden die Grundlagen zu Git Workflows definiert und anschließend einige Workflows betrachtet. Freilich nicht unerwähnt bleiben sollte die Tatsache, dass all die vorgestellten Mechanismen wie Code Review, Pull Request oder Merges von Werkzeugen unterstützt durchführbar sind. Dies soll Gegenstand dieses Beitrags sein.

Eigene Workflows umsetzen

Hat man Workflows erst einmal verstanden und einige Modelle erprobt, so möchte man oft einen maßgeschneiderten, dem gegenwärtigen Projekt oder unternehmensinternen Vorgehen entsprechenden Workflow entwickeln. Folgende Fragen sollte man sich stets stellen:

  • Bildet der Workflow den tatsächlichen Arbeitsalltag ab und verwendet Zweige nicht nur zum Selbstzweck? Brauche ich Long-Term-Support-Branches? Brauchen wir develop/master – oder reicht master? Weniger Zweigvarianten bedeuten weniger Aufwand.
  • Das bedeutet auch, sich Gedanken über Rollen zu machen: Wer ist für welche Art von Zweigen zuständig, welche Benutzer(gruppen) haben Schreib- und Leserechte auf welche Zweige?
  • Zweigübergänge und Berechtigungen festlegen: Wann wird von wem welche Operation durchgeführt?
  • Implikationen und Folgen der Übergänge bestimmen: Muss jemand informiert werden/müssen Tickets aktuell gehalten werden?
  • Zu guter Letzt stets hinterfragen: Macht der Workflow den Entwickleralltag tatsächlich einfacher und hilft Stakeholdern, den aktuellen Entwicklungsfortschritt effektiv zu verfolgen?

Doch designt man erst einmal einen Ablauf und formuliert Regeln, stellt man schnell fest: die beispielsweise vermeintlich einfache Vorgabe, sicherzustellen, dass der Masterzweig stets stabil und auslieferbar sein soll, zieht eine ganz Reihe von Implikationen mit sich. Einen Workflow umzusetzen bedeutet mehr als nur die Regeln zu formulieren und auf die Einhaltung der Vorgaben zu hoffen. Sprich: Wie verhindert man ganz konkret, dass ein Entwickler einen instabilen Feature-Zweig ohne Freigabe in den master-Zweig merged? Will man nach Möglichkeit ohne Lieutenant-Dictator-Ansatz oder Multi-Repository/Forks auskommen, also ein einziges zentrales Repository verwenden, um vor allem im Enterprise-Umfeld unnötigen Mehraufwand zu verhindern und die IT-Infrastruktur schlank halten, wird die Luft relativ schnell dünn.

Und so lassen sich Anforderungen an Software für Entwickler ableiten: Wir benötigen ein Werkzeug, welches Branching Modelle bzw. Workflows unterstützt, Zugangsberechtigungen auf Zweigebene besitzt und einen Mechanismus für Code Reviews bereitstellt.

Die denkbar einfachste Variante besteht darin, die lokale git-Kommandozeile mit den git flow extensions aufzurüsten. So können feature-, hotfix– und release-Zweige mit einfachen Kommandos erstellt werden. Das Ganze ist natürlich etwas umständlich und verlangt von jedem Entwickler neben Vertrautheit mit der git-Kommandozeile, einen ganzen Satz von Werkzeugen lokal zu installieren und zu verwalten. Weiterhin verhindert man damit nicht das Umgehen der Schreibrechte und hat noch keinen Mechanismus für Reviews geschaffen.

Alternativen könnten teamorientierte, webbasierte Git-Hostingservices wie GitHub oder BitBucket sein. Einem Webdienst seinen wertvollen Quelltext und interne Vorgänge anzuvertrauen löst bei den meisten Entscheidern ein mulmiges Gefühl aus. Wünscht man sich einen sicheren und flexiblen Ablageort für Softwareprojekte, führt meist kein Weg an selbst gehosteten Werkzeugen vorbei. Die meisten webbasierten Dienste bieten auch keine Möglichkeit, eigene Arbeitsfluss-Regeln zu forcieren; man ist stets an die Vorgaben der Plattform gebunden.

Git Workflows am Beispiel von Atlassian Stash

Möchte man “behind the firewall” mit wenig Aufwand git-basierte Entwicklung betreiben, Code Reviews und auch Workflows nach eigenen Vorstellungen umsetzen, bleibt nach der derzeitigen Marktsituation nur Atlassian Stash.

Mit Stash können Git Repositories gehostet und mit Zugriffskontrollen bis auf Branch-Ebene versehen werden. Dabei bildet Stash eine Art “Schale” um die blanken Git-Repositories. Alle git-Befehle werden per SSH oder HTTP an den Stash-Server gegeben und dort verarbeitet, bevor sie an das interne Repository weitergegeben werden. So können Befehle wie Push interveniert und auf ein Zugriffsschema angewendet werden.

Zu behaupten, man sei ganz frei in der Erstellung von Workflows, wäre nicht die ganze Wahrheit: Stash gibt ein gewisses Korsett vor.

  • Permanente Zweige für Produktion und Entwicklung, z. B. develop und master
  • Temporäre bzw. Entwicklungsbranches für Features, Bugfixes, Releases und Hotfixes.

Die Benennung der Präfixe ist frei wählbar, die Vorgaben entsprechen ebenfalls den gängigen Anforderungen von Workflows. Einziger Wermutstropfen: Zwar lassen sich die Präfixe frei wählen, aber eine Anpassung der Semantik (z. B. LTR Release und Release Candidate) eines Zweiges ist nicht möglich.

Möchte man Gitflow umsetzen, ist die Einrichtung denkbar einfach. Wir müssen lediglich einen develop-Zweig benennen, der Rest ist bei Stash bereits voreingestellt. Bugfix-Zweige sind in Gitflow nicht vorgesehen, diese könnte man also optional deaktivieren.

stash-workflow-model

Das ausgeklügelte Rollenkonzept mit Berechtigungen auf Branch-Ebene erlaubt es über die Vorgaben von Gitflow hinaus, frei einen Prozess zu definieren. Für das Beispiel haben wir uns entschieden, folgendes Rollenkonzept zu verwenden:

  • Die Benutzergruppe für Entwickler ist berechtigt Feature– und Hotfix-Zweige anzulegen.
  • Der Produktmanager (Ryan Lee) muss die Freigabe für die Integration von releases oder hotfixes in den master erteilen.
  • Die Release-Manager und Emma Paris bestimmen, wann von develop neue release-Zweige abgeleitet werden.

Die Umsetzung der Regeln kann beispielsweise so aussehen:

stash-branch-permissions

Freilich lassen sich nur mit Berechtigungen auf Zweigen oder dem Repository nicht alle Fälle abbilden:

  • Hotfixes müssen von master stammen und die Änderungen wieder nach develop fließen.
  • Features müssen von und nach develop entwickelt werden.
  • Änderungen an Release-Zweigen müssen wieder in develop zurückfließen.
  • … und so weiter

Mit der Stash-Hooks API wäre der geneigte Administrator sogar in der Lage, mithilfe eines entsprechenden Plugins auch diese Regeln zu forcieren.

Pull Requests & Code Reviews

Komplettiert wird das Paket durch Pull Requests. Möchte ein Entwickler eine Änderung in beispielsweise den Entwickler- oder Masterzweig bekommen, ist aber der aufgrund des Rollenkonzeptes nicht dazu berechtigt, helfen hier entsprechende Funktionen in Stash.

stash-pr

In ihrer Natur kaum anders als die gleichnamigen Mechanismen auf GitHub und Konsorten, wird so ein Code Review veranlasst, um eine Freigabe (Approval) zu erhalten, den Zweig in den Zielzweig integrieren zu dürfen. Stash bietet hier sogar die Möglichkeit, Reviews an Bedingungen zu knüpfen, wie beispielsweise mindestens zwei Approvals von Reviewern und, falls eine Integration mit dem CI-Server Bamboo eingerichtet ist, mindestens ein erfolgreicher CI-Build. (Feature-)Zweige können nach erfolgreichem Merge automatisch gelöscht werden.

Fazit & Ausblick: Von der Idee zur Auslieferung?

Mit diesem Wissen lassen sich effektive Workflows praktisch umsetzen. Hiermit geht auch die erste Artikelserie zu Ende: Begonnen mit dem Versuch, Git Workflows zu definieren, folgte ein Überblick über die gängigsten Workflow-Modelle. Das Design eigener, maßgeschneiderter Workflows und deren Umsetzung in der Praxis waren Gegenstand dieses Artikels.

Festzuhalten bleibt, dass Workflows kein Selbstzweck sein sollten, sondern stets einen Mehrwert für Entwickler und vor allem Stakeholder bieten sollten. Workflows sollen den Überblick über den aktuellen Stand der Entwicklung vereinfachen, um schneller bessere Entscheidungen für das Unternehmen treffen zu können. Branching-Modelle fügen sich generell gut in agile Entwicklungsmethoden ein, benötigen aber neben unterschiedlichen Zweigtypen klare Rollen und definierte Übergänge, um wirklich business-tauglich zu werden. Glücklicherweise ist die Umsetzung von Workflows dank der Unterstützung in diversen Softwarewerkzeugen in der Praxis bereits relativ schmerzlos möglich. Als Beispiel diente uns Atlassian Stash, welches das derzeit fortschrittlichste Werkzeug rund im Git im Enterprise-Segment darstellt.

Die berechtigte Frage könnte nun lauten: Kann man noch mehr erreichen und gar den gesamten Entwicklungsprozess mithilfe von Werkzeugen abbilden? Auch dies ist möglich, Atlassian bietet mit Git Essentials ein Paket, bestehend aus den hauseigenen Werkzeugen Bamboo, Stash, JIRA, JIRA Agile, um eine komplette Entwicklungsumgebung aus einer Hand aufzuziehen. Was damit über reine Git Workflows hinaus möglich ist und wie praxistauglich das propagierte “From Concept to Launch” tatsächlich ist, werden wir in künftigen Beiträgen betrachten.

Short URL for this post: http://wp.me/p4nxik-2fA
This entry was posted in Agile Methods and development, Atlassian Tools, Build, config and deploy and tagged , , , . Bookmark the permalink.

One Response to Git Workflows Tutorial 3: Workflows in der Praxis

  1. Johannes says:

    Die Artikel Serie zu Git Workflows gefällt mir sehr gut. Wir sind bei uns auf dem Stand, dass wir Git-Flow bisher 1:1 so verwenden wie vorgesehen. In deinem Artikel beschreibst du viel das Vorgehen mit Absicherungen bezüglich Zugriffsberechtigungen.
    Bei uns ist es nun so, dass wir den Workflow auch erweitern wollen, sodass weiterhin alle Features in Develop gemerged werden, aber man die Wahl hat, welche von den Features letztendlich für den Release verwendet werden sollen. Kennt da jemand geeignete Workflows oder Mechanismen, um dies abzubilden und auch nachvollziehen zu können, welche Features im Develop getestet wurden und welche im Release verwendet wurden.

Leave a Reply