Flusso di lavoro di revisione del codice in cui l'autore della richiesta pull deve unire

16

Diversi team della mia azienda praticano un flusso di lavoro di revisione del codice che non avevo mai visto prima. Sto cercando di capire il pensiero che sta dietro, con l'idea che c'è valore nel rendere coerente l'intera azienda. (Contribuisco a più codebase e sono stato innescato dalle differenze in passato.)

L'autore del codice invia una richiesta pull
Il revisore esamina il codice
- Se il revisore approva, lascia un commento sulla falsariga di "Sembra buono, sentiti libero di unire"
- Se il revisore ha dubbi, lascia un commento del tipo "Correggi i problemi minori X e Y, quindi unisci" (Per modifiche importanti, torna al passaggio 2)
L'autore del codice apporta modifiche se necessario, quindi unisce la propria richiesta pull

Ho le seguenti preoccupazioni:

In caso di approvazione al passaggio 3, questo flusso di lavoro crea un roundtrip apparentemente non necessario per l'autore della richiesta pull. Il revisore, che sta già esaminando il codice, potrebbe semplicemente fonderlo immediatamente.
Nel caso in cui vengano richieste modifiche al passaggio 3, l'agenzia per unire la richiesta pull ora spetta esclusivamente all'autore del PR. Nessuno oltre all'autore esaminerà le modifiche prima della fusione.

Quali sono alcuni altri vantaggi o svantaggi di questo flusso di lavoro? Questo flusso di lavoro è comune ad altri team di progettazione?

code-reviews pull-requests

— aednichols
fonte

5

Hai chiesto alle persone della tua organizzazione perché hanno scelto questo flusso di lavoro specifico? Probabilmente sono in una posizione migliore per illuminare i meriti rilevanti di noi. Vorremmo semplicemente speculare.

— Robert Harvey,

1

Cosa succede nella tua organizzazione quando il revisore scrive "Correggi il problema principale X"?

— Doc Brown,

8

Nella mia esperienza, è meglio che l'autore originale sia quello che fa l'unione nel caso ci sia un conflitto di unione da risolvere. L'autore originale è di solito quello che è meglio attrezzato per capire come risolvere un conflitto di unione.

— 17 del 26

Sarei curioso di sapere la logica qui. Dovresti chiedere ai tuoi colleghi e scriverlo come una risposta autonoma: qui potrebbe esserci un ottimo processo di pensiero o una logica. Non riesco proprio a trovarne uno in fretta.

— Thomas Owens

21

Nel primo caso, di solito è una cortesia. Nella maggior parte delle organizzazioni, le fusioni danno il via a una serie di test automatizzati che devono essere gestiti prontamente in caso di fallimento. Soprattutto se si è verificato un ritardo significativo tra il momento in cui è stata inoltrata una richiesta pull e il momento in cui è stata esaminata, è educato consentire che si unisca nel calendario dell'autore, quindi hanno il tempo di affrontare eventuali ricadute impreviste. Il modo più semplice per farlo è quello di lasciarli unire da soli.

Inoltre, a volte l'autore viene a conoscenza dei motivi in seguito che una richiesta pull non dovrebbe ancora essere unita. Forse la PR di un altro sviluppatore ha una priorità maggiore e causerebbe conflitti. Forse ha pensato a un caso d'uso scoperto. Forse un commento di recensione ha innescato un brainstorming che necessita di ulteriori indagini prima che il problema sia pienamente soddisfatto. L'autore è a conoscenza del codice e ha senso dare a lui o lei l'ultima parola su quando viene unito.

Sul secondo punto, è solo una questione di fiducia. Se non puoi fidarti delle persone per risolvere problemi minori senza essere ricontrollati, non dovrebbero funzionare per te. Se il problema è abbastanza grande da richiedere un'altra revisione dopo la correzione, affidati ai revisori per richiederne uno.

Detto questo, ogni tanto unisco le richieste pull di altri autori, ma di solito si tratta di modifiche molto semplici, o da fonti esterne, in cui mi prendo personalmente la responsabilità di guidare attraverso errori di automazione dei test.

— Karl Bielefeldt
fonte

2

Sembra che ci sia più varietà là fuori di quanto avessi immaginato. La mia esperienza con i test automatizzati è stata che i test vengono eseguiti sul ramo prima che venga unito, non dopo, diventando così un prerequisito per l'unione. Ho anche visto correzioni "minori" non riviste, inclusa la mia, che causavano bug.

— aednichols,

2

I test spesso vengono eseguiti sia come postcondizione che come condizione preliminare. È completamente possibile che le modifiche da più diramazioni siano in conflitto in modi non ovvi che non si presenterebbero come un conflitto di codice e causerebbero il fallimento dei test. Nel mio posto di lavoro, è necessario che una filiale sia aggiornata con la filiale di base, così come tutti i test che passano prima che sia un candidato per la fusione e la fusione avviene automaticamente se queste due condizioni sono soddisfatte. Non abbiamo sempre avuto quella prima condizione - prima di allora avevamo effettivamente problemi introdotti al maestro raramente nonostante ogni ramo passasse individualmente

— Matthew Scharley

3

Avere l'autore iniziale unire la propria richiesta pull è il mio flusso di lavoro preferito in piccoli team. Oltre ai vantaggi tecnici già menzionati (in termini di risoluzione dei conflitti di unione, ad esempio), penso che aggiunga valore a livello culturale: crea un senso di appartenenza.

Ho specificato l' autore iniziale per il caso (raro) in cui un altro sviluppatore avrebbe aggiunto commit alla richiesta pull aperta (trascinando il ramo della funzionalità work-in-progress e spingendo indietro ad esso). Ciò non accade spesso e risulterebbe da una conversazione di persona o da Slack: questi impegni aggiuntivi (da parte di qualcun altro) non dovrebbero atterrare lì a sorpresa! In questo contesto, per autore iniziale , intendo colui che ha inviato la richiesta pull.

— mkcor
fonte

2

Nella mia organizzazione siamo abbastanza nuovi alle richieste pull e la tua domanda è una su cui ho riflettuto.

Un'osservazione che vorrei aggiungere: in alcuni strumenti (usiamo TFS) potrebbe esserci un oggetto di lavoro associato alla richiesta pull.

In tal caso, diventa un po 'una seccatura tenere traccia di quando il revisore ha eseguito l'unione. In quello scenario lo sviluppatore deve quindi rivisitare il PR, aprire il bug o modificare la richiesta e contrassegnarlo come "risolto". Se lo contrassegniamo "risolto" troppo presto, i tester credono che la correzione sia già parte della build corrente.

TFS 2017 ha migliorato l'implementazione della richiesta pull. Ora lo sviluppatore può richiedere la richiesta pull per unire automaticamente tutte le condizioni (nessun conflitto di unione, approvazione da parte dei revisori e build non funzionanti). YMMV.

— 9Rune5
fonte

1

In questo modo, l'autore ha la possibilità di cambiare idea sulla sua branca, forse ha capito qualcosa che dovrebbe essere fatto in un modo diverso, e rimettere le spese aggiuntive per la revisione.

— gnasher729
fonte