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

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 risolti prontamente se falliscono. Soprattutto se c'è stato un ritardo significativo tra il momento in cui è stata presentata una richiesta di pull e quando è stata esaminata, è educato permetterlo di essere unito all'orario dell'autore, in modo da avere il tempo di affrontare qualsiasi ricaduta inattesa. Il modo più semplice per farlo è di farseli unire da soli.

Inoltre, a volte l'autore viene a conoscenza di motivi successivi che una richiesta di pull non deve ancora essere unita. Forse il PR di un altro sviluppatore è una priorità più alta e causerebbe conflitti. Forse pensava a un caso d'uso scoperto. Forse un commento di revisione ha innescato un brainstorming che richiede ulteriori indagini prima che il problema sia pienamente soddisfatto. L'autore sa di più sul codice e ha senso dargli l'ultima parola su quando verrà unito.

Sul secondo punto, è solo una questione di fiducia. Se non ti fidi delle persone che correggono problemi minori senza essere stati ricontrollati, non dovrebbero lavorare per te. Se il problema è abbastanza grande da richiedere un'altra revisione dopo la correzione, affidati ai revisori per chiederne una.

Detto questo, occasionalmente unisco le richieste di pull di altri autori, ma di solito sono cambiamenti molto semplici, o da fonti esterne, dove personalmente mi prendo la responsabilità di guidare attraverso qualsiasi errore di automazione del test.

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

Ho specificato l'autore iniziale per il (raro) caso in cui un altro sviluppatore aggiungeva commit alla richiesta di pull aperta (estraendo il ramo della work-in-progress e spingendolo indietro). Questo non succede spesso, e deriverebbe da una conversazione di persona o da Slack: questi commit aggiuntivi (da parte di qualcun altro) dovrebbero not atterrare lì di sorpresa! In questo contesto, per autore iniziale , intendo colui che ha inviato la richiesta di pull.

Nella mia organizzazione siamo abbastanza nuovi alle richieste di pull e la tua domanda è una che ho riflettuto su me stessa.

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

Se questo è il caso, diventa un po 'una seccatura per tenere traccia di quando il revisore ha eseguito l'unione. In tale scenario lo sviluppatore deve quindi rivisitare il PR, aprire il bug o modificare la richiesta e contrassegnarla come "risolta". Se lo segniamo "risolto" troppo presto, i tester credono che la correzione sia già parte della build attuale.

TFS 2017 ha migliorato la loro implementazione della richiesta pull. Ora lo sviluppatore può richiedere che la richiesta di pull si unisca automaticamente se tutte le condizioni sono soddisfatte (nessun conflitto di fusione, approvazione dei revisori e nessuna build danneggiata). YMMV.

In questo modo, l'autore ha la possibilità di cambiare idea sul suo ramo, forse ha capito qualcosa che dovrebbe essere fatto in un modo diverso, e riporterà le spese aggiuntive per la revisione.