Workflow zur Codeüberprüfung, in dem der Autor der Pull-Anforderung zusammengeführt werden muss

Mehrere Teams in meinem Unternehmen üben einen Code-Überprüfungs-Workflow aus, den ich noch nie zuvor gesehen habe. Ich versuche, das Denken dahinter zu verstehen, mit der Idee, dass es Wert ist, das gesamte Unternehmen konsistent zu machen. (Ich trage zu mehreren Codebasen bei und wurde durch die Unterschiede in der Vergangenheit in Mitleidenschaft gezogen.)

1. Der Autor des Codes sendet eine Pull-Anfrage
2. Der Prüfer überprüft den Code
3. • Wenn der Prüfer zustimmt, hinterlässt er einen Kommentar wie folgt: "Sieht gut aus, Sie können ihn gerne zusammenführen."
   • Wenn der Prüfer Bedenken hat, hinterlässt er einen Kommentar wie "Bitte beheben Sie kleinere Probleme X und Y und führen Sie sie dann zusammen." (Bei größeren Änderungen kehren Sie zu Schritt 2 zurück.)
4. Der Codeautor nimmt bei Bedarf Änderungen vor und führt dann seine eigene Abrufanforderung zusammen

Ich habe folgende Bedenken:

• Im Fall der Genehmigung in Schritt 3 wird durch diesen Workflow ein scheinbar unnötiger Hin- und Rückflug zum Pull-Request-Autor erstellt. Der Prüfer, der sich den Code bereits ansieht, könnte ihn einfach sofort zusammenführen.

• Im Falle von Änderungen, die in Schritt 3 angefordert wurden, liegt die Agentur, die die Pull-Anforderung zusammenführt, jetzt ausschließlich beim PR-Autor. Niemand außer dem Autor wird sich die Änderungen vor dem Zusammenführen ansehen.

Welche weiteren Vor- oder Nachteile hat dieser Workflow? Ist dieser Workflow bei anderen Entwicklungsteams üblich?

Im ersten Fall ist es normalerweise eine Höflichkeit. In den meisten Organisationen starten Zusammenschlüsse eine Reihe automatisierter Tests, die bei Fehlschlagen umgehend behoben werden müssen. Insbesondere wenn es zwischen dem Einreichen eines Pull-Antrags und der Überprüfung zu einer erheblichen Verzögerung kam, ist es höflich, zuzulassen, dass er in den Zeitplan des Autors aufgenommen wird, damit er Zeit hat, sich mit unerwarteten Ausfällen zu befassen. Der einfachste Weg, dies zu tun, ist, sie selbst zusammenführen zu lassen.

Manchmal werden dem Autor später auch Gründe dafür bekannt, dass eine Pull-Anfrage noch nicht zusammengeführt werden sollte. Möglicherweise hat die PR eines anderen Entwicklers eine höhere Priorität und würde Konflikte verursachen. Vielleicht dachte sie an einen ungedeckten Anwendungsfall. Möglicherweise hat ein Überprüfungskommentar ein Brainstorming ausgelöst, das einer weiteren Untersuchung bedarf, bevor das Problem vollständig gelöst ist. Der Autor kennt den Code am besten, und es ist sinnvoll, ihm das letzte Wort darüber zu geben, wann er zusammengeführt wird.

Beim zweiten Punkt geht es nur um Vertrauen. Wenn Sie nicht darauf vertrauen können, dass andere Personen kleinere Probleme beheben, ohne dass dies überprüft wird, sollten sie nicht für Sie arbeiten. Wenn das Problem so groß ist, dass nach dem Fix eine weitere Überprüfung erforderlich ist, sollten Sie den Überprüfern vertrauen, dass sie eine weitere Überprüfung anfordern.

Abgesehen davon füge ich gelegentlich die Pull-Anfragen anderer Autoren zusammen, aber es sind normalerweise entweder sehr einfache Änderungen oder externe Quellen, bei denen ich persönlich die Verantwortung für das Durchführen von Fehlern bei der Testautomatisierung übernehme.

Es ist mein bevorzugter Workflow in kleinen Teams, wenn der Erstautor seine eigene Pull-Anfrage zusammenführt. Zusätzlich zu den bereits erwähnten technischen Vorteilen (zum Beispiel bei der Lösung von Zusammenführungskonflikten) denke ich, dass dies einen Mehrwert auf kultureller Ebene darstellt: Es schafft ein Gefühl von Eigenverantwortung.

I angegebenen Anfang Autor für den (seltenen) Fall , wenn ein anderer Entwickler Commits zur offenen Pull - Anforderung hinzufügen würde (den Work-in-progress Zweig ziehen und sie zurückzudrängen). Dies kommt nicht oft vor und resultiert aus einem persönlichen Gespräch oder über Slack: Diese zusätzlichen Commits (von jemand anderem) sollten nicht überraschend dort landen! In diesem Zusammenhang von Anfang Autor, meine ich denjenigen, der die Pull - Anforderung vorgelegt.

In meiner Organisation sind wir ziemlich neu in Bezug auf Pull-Anfragen und Ihre Frage habe ich mir selbst gestellt.

Eine Bemerkung, die ich hinzufügen möchte: In einigen Tools (wir verwenden TFS) ist möglicherweise ein Arbeitselement mit der Pull-Anforderung verknüpft.

Wenn dies der Fall ist, wird es ein bisschen mühsam, den Überblick zu behalten, wann der Prüfer die Zusammenführung durchgeführt hat. In diesem Szenario muss der Entwickler den PR erneut aufrufen, den Fehler oder die Änderungsanforderung öffnen und als "behoben" markieren. Wenn wir es zu früh als "behoben" markieren, glauben die Tester, dass der Fix bereits Teil des aktuellen Builds ist.

TFS 2017 hat die Umsetzung der Pull-Anfrage verbessert. Jetzt kann der Entwickler anfordern, dass die Pull-Anforderung automatisch zusammengeführt wird, wenn alle Bedingungen erfüllt sind (kein Zusammenführungskonflikt, Genehmigung durch Prüfer und keine fehlerhaften Builds). YMMV.

Auf diese Weise hat der Autor die Möglichkeit, seine Meinung über seine Branche zu ändern. Vielleicht hat er etwas herausgefunden, das auf eine andere Art und Weise getan werden sollte, und die zusätzlichen Kosten erneut zur Überprüfung bereitgestellt.