11.12.2021 -
Im Dschungel der Projektmanagement-Fachbegriffe taucht Pull Request Workflow immer wieder auf. Was ist das eigentlich und warum ist es interessant? Code Reviews, die auf Pull Requests basieren, fördern den Austausch von Wissen und Ideen im Team, machen aber auch den Fortschritt im Projekt sichtbar und nachvollziehbar. Solche Reviews wollen allerdings gut geplant sein, denn sie kosten Zeit und bergen nicht selten auch Konfliktpotential. Jan Petzold ist auf der Suche nach einem zeitgemäßen und idealen Pull Request Workflow, damit die Vorteile der Reviews optimal ausgenutzt werden können, ohne dass der Zeitaufwand für das Erstellen der Reviews den Fortschritt im Projekt beeinträchtigt. Wir fassen seinen Artikel für Heise.de im Folgenden für Sie zusammen.
Weiterlesen »
11.12.2021 -
Im Dschungel der Projektmanagement-Fachbegriffe taucht Pull Request Workflow immer wieder auf. Was ist das eigentlich und warum ist es interessant? Code Reviews, die auf Pull Requests basieren, fördern den Austausch von Wissen und Ideen im Team, machen aber auch den Fortschritt im Projekt sichtbar und nachvollziehbar. Solche Reviews wollen allerdings gut geplant sein, denn sie kosten Zeit und bergen nicht selten auch Konfliktpotential. Jan Petzold ist auf der Suche nach einem zeitgemäßen und idealen Pull Request Workflow, damit die Vorteile der Reviews optimal ausgenutzt werden können, ohne dass der Zeitaufwand für das Erstellen der Reviews den Fortschritt im Projekt beeinträchtigt. Wir fassen seinen Artikel für Heise.de im Folgenden für Sie zusammen.
Was spricht dafür?
Neben der Verbesserung von Wissensaustausch und der Nachvollziehbarkeit des Projektfortschritts sprechen andere Gründe für die Verpflichtung zu Code-Reviews über Pull Requests. Sie sorgen zum Beispiel dafür, dass es zu einer erhöhten Lesbarkeit und einem einheitlichen Stil im Projekt kommt. Wenn von der Regel abgewichen wird, lässt sich das sofort erkennen. Ein Code Review kann hervorragend als Diskussionsbasis dienen. Der Code sagt die Wahrheit und lässt das Potential für Verbesserungen erkennen, während er gleichzeitig auch Missverständnisse aufzeigt. Ein interessanter Aspekt ist, dass Pull Requests asynchron funktionieren. Jedes Teammitglied kann also Pull Requests in den Alltag einbauen. Auch das gemeinsame Arbeiten in unterschiedlichen Zeitzonen kann so erleichtert werden.
Technischer Ablauf
Technisch betrachtet sind Pull Requests oft an ein Versionsverwaltungssystem wie Gitflow gekoppelt, müssen sie aber nicht. Hier ein vereinfachtes Beispiel für einen agilen Entwicklungsprozess in einem Team:
Es beginnt mit einem Thema oder Feature, das in einer Story oder einem Ticket konkretisiert wird. In einem Prozess von Planning und Grooming werden die Kriterien definiert und ausgearbeitet. Gegebenenfalls erfolgt eine Schätzung. Im ersten Sprint legt der Product Owner die Prioritäten fest. Die Entwicklung beginnt und über den Entwicklungszweig wird ein neuer Branch erstellt. Ist die Entwicklung abgeschlossen, erfolgen die Tests und anschließend der Review. Dieser Review erfolgt über Pull Requests. Erfolgt die Freigabe, wird der jeweilige Branch mit dem Hauptprojekt wieder vereint, was sich Merge nennt. Hier kommt oft auch noch ein Schritt der Qualitätsfreigabe ins Spiel. Dann folgt der Release.
Varianten im Ablauf
Diese Abfolge hat sich weitgehend etabliert, wobei sie je nach Unternehmen und personeller Besetzung variiert. Allerdings finden sich von Unternehmen zu Unternehmen starke Unterschiede in der Gestaltung des Pull-Request-Workflows. Jan Petzold hat seine Erfahrungen mit Teams mit jeweils drei bis zehn Mitgliedern gemacht. Bei dieser Teamgröße gibt es verschiedene Vorgehensweisen. Es wird entweder jedem Entwickler ein Pull Request zugewiesen und erst nachdem alle den jeweiligen Pull Request begutachtet, geprüft und freigegeben haben, kann der Merge stattfinden. Es gibt aber auch die Variante, dass der leitende Ingenieur oder Architekt allein für das Prüfen und Genehmigen der Pull Requests verantwortlich ist, wobei die anderen Teammitglieder entweder optional Einsicht nehmen oder auch nicht an dieser Aufgabe beteiligt werden. Es besteht auch die Möglichkeit, dass ein bestimmter Entwickler jeweils die Pull Requests eines anderen Entwicklers prüft. Diese Variante nennt sich Solo-Reviewer. Dabei ist es sinnvoll, die Aufgaben jeweils nach Fachkenntnissen zu vergeben. Statt eines Solo-Reviewers kann auch ein Team von Reviewern mit verschiedenen Fachkenntnissen den Review übernehmen. Letztendlich gibt es auch die Ausformung, die allen Teammitgliedern die Möglichkeit zum Review lässt. Sobald eine bestimmte Anzahl von Teammitgliedern den Pull Request freigegeben hat, gilt er als genehmigt.
Reviewen im echten Arbeitsleben
Jan Petzold ist ein Fan der Variante, in der alle oder zumindest mehrere Teammitglieder den Review machen. So werden Flaschenhalssituationen vermieden und es ist wahrscheinlicher, dass Fehler und Missverständnisse entdeckt werden. Scheitern kann das Reviewsystem entweder an mangelndem Fachwissen oder an Unwillen. Viele Aspekte des Review können auch ohne spezielles Fachwissen genehmigt werden. Schließlich bleibt noch festzulegen, wie die Teammitglieder davon erfahren, dass es einen neuen Pull Request gibt, der Beachtung wünscht. Im Großraumbüro kann das mündlich erfolgen. Üblicher sind wohl Chat oder Email-Nachrichten. Einige schwören auf Benachrichtigungen über Slack oder Bitbucket, also auf automatisierte Messages, sobald ein neuer Pull Request vorliegt. Im Kickoff jedes Projekts sollte einmal darauf eingegangen werden, damit klar ist, wie die Benachrichtigung erfolgen soll. Es macht alles einfacher, wenn von Anfang an klar ist, wie viele Reviewer es gibt, wer das ist, welchen Umfang die Analyse und Freigabe haben müssen und von wem schließlich der Merge ausgelöst wird. Sinnvoll ist es, festzulegen, dass zwingend eine Reaktion auf jeden Review folgen muss. Der Reviewer ist verpflichtet, zu signalisieren, wann der Review abgeschlossen ist, allein um ständige Nachfragen nach dem Ergebnis zu vermeiden. Der Autor des Pull Requests sollte allerdings ebenso verpflichtet werden, auf alle Kommentare zu antworten, auch wenn es sich nur um eine knappe Antwort handelt. Jan Petzold begrüßt auch Offline-Diskussionen, die oft schneller zur Abarbeitung von Kommentaren führen. Regeln müssen sein, denn ein Review ist leider oft die erste Aufgabe, die in stressigen Zeiten unter den Tisch fällt. Er schlägt vor, einen Zeitplan zu machen, so dass jedes Teammitglied immer direkt morgens oder nach der Mittagspause Reviews bearbeitet, bis sie erledigt sind.
« Alle Beiträge