Git Workflows Teil 1: Warum wir Workflows brauchen

In dieser Artikelserie werden wir das in der Software-Entwicklung inzwischen omnipräsente Phänomen Git Workflows näher betrachten. Im ersten Teil betrachten wir das Wie und Warum hinter Git Workflows, bevor wir uns im zweiten Teil konkreten Workflow-Modellen widmen. Im dritten Teil beantworten wir die Frage, wie man eigene Workflows mithilfe von Werkzeugen geschickt umsetzt.

Ein typisches Szenario in einer Softwareschmiede könnte so aussehen: Eine gemeinsame Codebasis, mehrere Mitarbeiter oder sogar Teams und ein stabiler master-Zweig, von dem aus veröffentlicht werden soll. Ein “zweig-affines” Versionskontrollsystem soll her, denn Zweige gehören zum guten Ton – also setzt man auf Git. Warum eigentlich? Benutzt jeder heutzutage. Wie das im Detail funktioniert, ist ja auch nicht so wichtig.

Ein Team soll eine neue Funktionalität entwickeln und hat, wie es sich gehört, einen neuen Zweig erstellt und an diesem bereits einige Wochen fleißig gearbeitet. Trotz der Absichtsformulierung “ab und zu” die neusten Änderungen aus master in den Feature-Zweig zu integrieren, damit alles auch schön aktuell bleibt, ist die letzte Aktualisierung doch bereits eine ganze Weile her – keine Zeit für sowas! In der Zwischenzeit sind bereits unzählige Änderungen von anderen Teams eingeflossen und größere Refactoringarbeiten an der Codebasis vorgenommen worden, klar. Die Unterschiede zwischen Feature- und Mainline-Zweig sind inzwischen groß. Der sowieso unter Zeitdruck stehende Entwickler baut bzw. hackt die Mainline mit dem Feature-Zweig zusammen und pusht das Feature in den Hauptzweig. Was auf der lokalen Entwicklermaschine noch so schön funktioniert hat, baut der letzte Woche eiligst eingehängte CI-Server auf einmal nicht mehr. Die stundenlange Fehlersuche in der Commit-History beginnt…

Im nächsten Sprint Review einigt man sich darauf, endlich einen dieser Workflows zu implementieren – damit wird laut StackOverflow alles besser.

Alles auf Anfang: Die Motivation hinter Software

Es wirkt beinahe so, als würden manche Teams Workflows zum Selbstzweck einsetzen – weil man es eben so tut. Ebenfalls erschließt sich anderen Projektbeteiligten oder gar Entscheidern die Notwendigkeit dieser Arbeitsprozesse innerhalb eines Entwicklerteams oftmals nicht direkt. Um die komplexe Thematik rund um Workflows zu verstehen, muss man sich auf die grundlegenden Gedanken, die hinter Versionsverwaltung, ja gar hinter Software allgemein stehen, besinnen.

Was ist der Zweck von Software? Menschen zu helfen. Software abstrahiert Probleme und soll Menschen täglich dabei helfen, die Probleme in ihrem Kontext besser, einfacher und schneller zu bewältigen.

Der Zweck eines Software-Entwicklungsprozesses ist es, Menschen zu helfen, Software einfacher, schneller, besser zu veröffentlichen. Software besteht aus Anforderungen z.B. in Form von User Stories, welche Geschäftsziele repräsentieren. Prozessrahmenmodelle wie Scrum helfen den Entwicklern, ihre Arbeit entsprechend diesen Zielen zu priorisieren.

Genauso gibt es Software für Entwickler, die Entwicklern dabei hilft, einfacher Software zu erstellen und zu veröffentlichen. Alltägliches Werkzeug ist zum Beispiel die Entwicklungsumgebung, der Issue-Tracker und die Versionskontrolle.

Von Zweigaktualiserungen und Torwächtern: Pull Requests

Die Hauptaufgabe von Versionskontrolle ist, Entwicklern beim Schreiben von Software zu helfen und Änderungen zwischen Team-Mitgliedern zu synchronisieren und regelmäßig zu sichern. Die zweite Aufgabe ist Konfigurationsmanagement: Parallele Entwicklungsstränge verwalten, alte Versionen pflegen, neue Funktionen prototypisch implementieren und so weiter.

Das Erstellen von Zweigen (Branching) ist immer mit einem gewissen Integrationsaufwand verbunden. Arbeitet man im Team an einem Projekt, gibt es in der Regel ein zentralisiertes Repository als gemeinsamen Ablageort. Vielleicht ist sogar eine Continuous Delivery-Pipeline aufgesetzt, sodass jede Änderung am master-Zweig in ein potenziell auslieferbares Artefakt mündet.

Auf einmal kommen Fragen auf, die die Diskussion um Branching anheizt:

  • Ist jetzt jeder Entwickler selbst dafür verantwortlich, dass seine Änderungen in den Hauptzweig integrierbar sind? Falls ja, wie stellt man sicher, dass die Änderungen auch keine Regressionen hervorrufen?
  • Wem vertraue ich soweit, dass die Änderungen auf dem master-Zweig nicht im Desaster enden?
  • Wie verhindere ich, dass ein unachtsamer Entwickler einen force-push auf den master-Zweig macht?
  • Habe ich Vorkehrungen getroffen, sodass ich im Fehlerfall schnell die Ursache herausfinden kann?
  • Wer erteilt die Freigabe für die Integration eines neuen Features?
  • Können Stakeholder eigentlich verstehen, was wir da warum tun?

Zwei Konzepte können helfen, etwas mehr Klarheit zu schaffen. Klar definierte Regeln für (periodisches) Branch Updating und die Einführung eines Gatekeepers.

GatekeepingBranchUpdating

Branch Updating beschreibt den Vorgang, bei dem die Änderungen des Zielzweiges – also beispielsweise master – regelmäßig in unseren aktuellen Entwicklungszweig integriert werden.

Ein Gatekeeper beschreibt eine Rolle oder einen Mechanismus, welcher festlegt, dass eine Person oder ein Programm vor dem Integrieren eines Zweiges die Änderungen vorab auf Korrektheit prüft. Das kann beispielsweise ein Code Review eines Entwicklers oder ein Build eines Continuous Integration-Servers sein.

Ein beliebter Prozess des Gatekeepings findet in Form von Pull Requests statt, bei denen ein Entwickler ohne Schreibrechte auf einen kritischen Zweig wie master die Anfrage zur Integration seiner Änderungen an einen berechtigten Integrator stellt. Dazu benötigt man wiederum ein Rollenkonzept, welches klar die Zuständigkeiten und Rechte regelt.

Und spätestens jetzt wird ersichtlich, dass eine Art Prozess her muss, der irgendwo dokumentiert werden sollte: Ein Workflow.

Die Definition eines DVCS (Git)- Workflows

Git bzw. VCS-Workflows liefern einen strukturierten Ansatz für die Software-Entwicklung mit vielen Zweigen. Zusammengefasst sollte ein Workflow folgende Eigenschaften besitzen:

  • Ein Workflow sollte Stakeholdern, Projektmanagern und IT-Betrieb dabei helfen, besser zu verstehen, was gerade in der Entwicklung vor sich geht.
  • Zweige sollten dafür benutzt werden, ein einziges Problem/Feature abzubilden.
  • Man sollte zwischen öffentlichen/permanenten und privaten/temporären Zweigen unterscheiden.
  • Öffentliche Zweige müssen zu jeder Zeit von Projektverantwortlichen freigeb- und auslieferbar sein.
  • Vorgänge, wie der Entwicklungsbeginn eines neuen Features, Merges oder Deployments, sollten nicht ohne entsprechende Freigaben von Projektverantwortlichen stattfinden können, d.h. es sollte ein Rollenkonzept abzubilden sein.

Mit dieser Definition gerüstet, betrachten wir den einfachst möglichen Workflow.

Das einfachste Beispiel: master-only

Der Aufbau ist denkbar einfach; den einzigen zentralen Zweig stellt der Master-Zweig dar. Features werden in privaten Zweigen entwickelt. MasterOnly Die Grundregel lautet, öffentliche Zweige als unveränderlich, feststehend mit sauber gehaltener Historie zu behandeln. Private Feature-Zweige werden als veränderbares und lediglich temporär existierendes Konstrukt betrachtet.

  • Erstelle einen temporären Zweig (feature) aus einem öffentlichen Zweig (master) heraus.
  • Schreibe Änderungen regelmäßig in den temporären Zweig.
  • Sobald die Arbeiten abgeschlossen sind, räume die Historie auf und sorge für eine saubere Integrierbarkeit.
  • Führe den Zweig mit master zusammen.
  • Lösche den nun überflüssigen Feature-Zweig.

Vorteil dieses Workflows ist seine Einfachheit. Der große Nachteil ist die fehlenden Zuständigkeiten, schlechte Skalierbarkeit für größere Projekte und die fehlende Möglichkeit, Legacy-Versionen weiterhin zu pflegen. Die Grundidee wird aber bestehen bleiben, und bei der Betrachtung weiterer Workflows werden auf dieser Grundlage weitere Ansätze betrachtet und schrittweise komplexer modelliert.

Diesen widmen wir uns im zweiten Teil dieser Artikelserie, bevor wir uns mit dem Thema des Workflow-Designs und der Umsetzung mithilfe von Software befassen.

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

Leave a Reply