Nachgebessert: Pull-Request-Workflows in der Praxis
Seite 2: Praxis im Projekt und Tooling
Generell ist es sinnvoll, ein gemeinsames Vorgehen für den Pull-Request-Workflow im Kickoff eines Projekts festzulegen – vergleichbar zu Definition of Done/Definition of Ready. Dabei entstehen gemeinsame Konventionen, wie sie die folgenden Beispiele kurz beschreiben:
- Wie viele Reviewer müssen den Pull Request genehmigen?
- Verantwortung des Reviewers (Code nur lesen oder Branch auschecken und testen)
- Wer veranlasst den Merge nach Abnahme?
- Minimalanforderungen an Beschreibungstexte
- Kommunikationsfluss bei Rückfragen/Anmerkungen
- Umgang mit TODO- bzw. FIXME-Anmerkungen
- Grad der Testabdeckung (Happy Path/Fehlerbehandlung/Ende-zu-Ende)
- Automatisches Linting/Code-Formatierung
Manche Teams verwenden dazu auch Checklisten, die jeder Pull Request abzuarbeiten hat – auch in Bezug auf Continuous Integration. Die bekanntesten Werkzeuge für die Bearbeitung von Pull Requests sind sicherlich die in die jeweiligen Plattformen integrierten Ansichten von GitHub und Bitbucket. Vieles lässt sich darin bereits ableiten – links stehen die geänderten Dateien, rechts eine Diff-Ansicht inklusive (gewichtetem) Kommentar, Reaktion und einer kleinen Task-Funktion zur Kennzeichnung (s. Abb. 1).
Eine Reaktion nach dem Review sollte verpflichtend sein (Bringschuld Reviewer), um regelmäßige Nachfragen zum Status zu vermeiden. Andererseits sollte auch jeder Kommentar eine Antwort erhalten (Bringschuld Autor). Darüber hinaus ist eine Offline-Diskussion zu begrüßen, deren Ergebnis kommentiert in den Pull Request einfließen sollte.
Häufig verzögern sich Pull Requests, weil keines der Teammitglieder nur auf neue Code-Reviews wartet. Um eine kontinuierliche Betreuung der Pull Requests sicherzustellen, helfen einfache Regeln. Empfehlenswert ist beispielsweise, dass jeder Kollege morgens oder nach der Mittagspause offene Pull Requests bearbeitet – je nach Aufkommen gegebenenfalls auch zweimal am Tag.
