Nachgebessert: Pull-Request-Workflows in der Praxis

Code-Reviews auf Basis von Pull Requests fördern nicht nur den Wissens- und Meinungsaustausch im Team, sie machen außerdem den Projektfortschritt nachvollziehbar. Die Reviews bergen aber auch Konfliktpotenzial und sind zeitaufwendig. Sorgfältige Planung ist daher essenziell.

Architektur/Methoden  –  19 Kommentare
Nachgebessert – Pull-Request-Workflows in der Praxis

(Bild: Shutterstock / iX)

Code-Reviews sind eine feine Sache: Sie dienen dazu, verschiedene Meinungen einzuholen, Wissen zu teilen und nicht zuletzt den Fortschritt im Projekt konkret und greifbar zu machen. Alle Kollegen lernen mit der Zeit automatisch hinzu. Code-Reviews kosten aber auch Zeit und können zu unangenehmen Konflikten im Team führen. Wie sollte daher ein zeitgemäßer Pull-Request-Workflow aussehen und wie lassen sich dabei trotz der verpflichtenden Reviewzyklen Beeinträchtigungen des Projektfortschritts vermeiden?

Gründe für Pull Requests

Neben den genannten Gründen, die für ein verpflichtendes Code-Review über Pull Requests sprechen, tragen sie auch zu höherer Konsistenz der Umsetzung (einheitlicher Stil, Lesbarkeit) in einem Projekt bei. Abweichungen von Konventionen lassen sich damit ebenso erkennen wie andere verwandte Probleme. Letztlich verringert sich dadurch auch die langfristig immer entstehende technische Schuld.

Ein Code-Review stellt auch eine gemeinsame Diskussionsbasis dar – trotz Brainstorming, Akzeptanzkriterien und Whiteboards steht die Wahrheit letztlich doch nur im Code. Missverständnisse, Lücken und Verbesserungspotenzial werden ersichtlich. Weiterhin funktionieren Pull Requests asynchron, sodass jeder Kollege Code-Reviews in seinen Arbeitstag eintakten kann (vergleichbar zu E-Mail). Das hilft auch bei der Arbeit in verteilten Teams und unterschiedlichen Zeitzonen.

Integration in den agilen Entwicklungsprozess

Technisch sind Pull Requests stark an die Arbeit im Versionsverwaltungssystem Git (beispielsweise Gitflow) gekoppelt – wobei dieses allerdings keine Bedingung ist. In vielen Teams sieht ein agil geprägter Entwicklungsprozess folgendermaßen aus (Kurzfassung):

  1. Ein Thema (z.B. Feature) wird in einem Ticket (Story) hinsichtlich der Anforderungen konkretisiert
  2. Besprechung der Story in Grooming/Planning, Schärfung der Akzeptanzkriterien
  3. Sofern nötig/gewünscht erfolgt eine Schätzung
  4. Product Owner legt Prioritäten der Storys im Rahmen des Sprints fest
  5. Entwicklung startet und ein neuer Branch wird ausgehend vom Entwicklungszweig erstellt
  6. Nach Abschluss der Entwicklung und Aktualisierung/Durchlauf der Tests erfolgt das Review via Pull Requests
  7. Nach Abnahme wird der Branch wieder mit dem Hauptzweig zusammengeführt (Merge)
  8. Gegebenenfalls Deployment auf Testumgebung und Abnahme/QA
  9. Je nach Releasezyklus werden Entwicklungszweig und Master-Branch zusammengeführt
  10. Das Release erfolgt (alternativ: Continuous Deployment)

Die beschriebene Abfolge dürfte inzwischen gängig und etabliert sein, wobei es natürlich je nach Personalsituation, Unternehmen und den individuellen Vorerfahrungen Abweichungen gibt.

Review-Konstellationen

In der Ausgestaltung des Pull-Request-Workflows finden sich definitiv Unterschiede. Folgende Ausprägungen sind nach den Erfahrungen des Autors in Teams mit mindestens drei und maximal zehn Entwicklern in der Praxis gängig.

  • Alle reviewen alles: Ein Pull Request wird jedem Entwickler des Teams zugewiesen. Erst nachdem alle den PR gesehen, überprüft und genehmigt haben, erfolgt der Merge.
  • Lead-Engineer reviewed alles: Das Team hat einen verantwortlichen Lead-Engineer/Architekten, der alle Pull Requests prüft. Andere Kollegen reviewen optional.
  • Solo-Review: Ein Entwickler entwickelt und ein anderer überprüft. Auswahl entweder nach Fachkenntnis/Vorerfahrung oder zufällig.
  • Spezialisten-Review: Mehr als ein Entwickler wird nominiert, Review je nach Erfahrung/Spezialisierung (z. B. Java-Entwickler reviewt Backend-Pull-Requests)
  • Fullstack-Review: Mehr als ein Entwickler wird nominiert, Review unabhängig von Vorerfahrung/Spezialisierung, Auswahl je nach Auslastung oder Zufall
  • First come, first merge: Alle Entwickler werden informiert, sobald eine bestimmte Zahl an Genehmigungen vorliegt (z.B. zwei) erfolgt der Merge.

Es ist generell empfehlenswert, alle Kollegen zu informieren. Dadurch kommt es zwar zu einem gewissen "Grundrauschen" in der Kommunikation, das von manchem als störend empfunden wird. Das Problem sollte dann im Rahmen einer Retrospektive diskutiert werden.

In den meisten Projekten sollte es sich als ineffizient erweisen, alle Kollegen alles reviewen lassen. Ein alleiniger Lead-Engineer bildet wiederum häufig einen Flaschenhals. Bewährt hat sich ein Minimum von zwei Reviewern. Die sollte das Team entweder nach dem Schema Junior/Senior nominieren oder aus den gerade verfügbaren Kollegen rekrutieren.

Idealerweise können alle Entwickler eines Teams jeden Pull Request reviewen. Häufig scheitert das aber an Spezialisierungen, Vorwissen oder auch Unwillen. Gerade in kleineren Teams finden sich die möglichen Reviewer daher meist "automatisch". Unabhängig von Spezialisierungen finden sich zahlreiche Aspekte wie Lesbarkeit, Kommentare, Namensgebung, Methodenlänge oder Strukturierung, die in jedem Pull Request relevant sind. Insofern kann wertvoller Input auch von Kollegen aus anderen "Welten" einfließen. Letztlich sind regelmäßige Reviews oft auch ein wichtiger Schritt auf dem Weg der Weiterentwicklung zum Fullstack-Entwickler.

Bleibt noch die Frage, wie die Kollegen von einem neuen Pull Request erfahren? Sitzen alle im selben Büro, kann ein Zuruf genügen. Praktischer ist aber ein eigener Channel im Chat. Der Autor des Pull Request schreibt dann eine kurze Nachricht. Alternativ lässt sich die Benachrichtigung über Tool-Integrationen wie Bitbucket und Slack automatisieren.