Il modo migliore per tenere traccia e applicare le revisioni tra pari prima del commit

Question

Mi chiedevo quale meccanismo hanno usato le persone per imporre e tenere traccia delle revisioni tra pari per impegnarsi in SVN.

Per ogni commit che voglio essere in grado di tracciare se le persone hanno avuto una revisione tra pari (non sono sicuro che far rispettare una regola in cui non possono impegnarsi sia una buona idea, la mia sensazione è che non dovrebbe essere applicato in quanto esiste probabilmente un motivo valido per eseguire il commit senza una peer review), ma i commit non revisionati dovrebbero poter essere monitorati in modo che prima di una release possiamo visualizzare tutti questi commit.

Answer 1

Puoi richiedere a ogni sviluppatore di aggiungere il tag dello sviluppatore di revisione al commit in un formato fisso come [REV: XYZ]. Ciò consente di filtrare la cronologia. Come menzionato qui, è possibile utilizzare gli hook pre-commit dello strumento di versioning del codice sorgente per imporre questo, se necessario.

Quindi è necessario comunicare a tutti gli sviluppatori la regola che nessun codice può essere eseguito senza una revisione tra pari. Mostra anche i vantaggi di rivedere il codice prima di impegnarti. I primi mesi, qualcuno dovrebbe controllare la cronologia di commit per commit senza tag revisore. Se ne trovano, chiedi agli sviluppatori perché hanno fatto una recensione e con chi. Quando non è stata effettuata alcuna revisione, ricordare loro la regola. Se alcuni sviluppatori violano questa regola consapevolmente più volte, potrebbero esserci ripercussioni, ma la pressione dei pari di solito impedisce che ciò accada.

Normalmente, non ci sono scuse per non fare una recensione quando questa regola è in vigore. Soprattutto il "Ma ho dovuto correggere rapidamente questo bug per consegnare al cliente la versione fissa" non può essere una scusa, perché è più probabile che uno sviluppatore commetta errori in fretta.

Answer 2

Questa domanda sembra una pubblicità per un VCS distribuito come git o bzr: è necessario che gli sviluppatori siano in grado di eseguire il commit delle modifiche spesso, ma sul proprio ramo, che viene quindi rivisto prima di essere inserito nel repository centrale.

Answer 3

Personalmente posso spesso impegnarmi a svn vicino a 50 volte al giorno, quindi non mi piacerebbe; # 836; 'non mi piace;)

So che il plugin greenhopper di Atlassian per jira può essere eseguito come hook pre-commit per richiedere un riferimento jira nel commit. Se usi greenhopper anche per pianificare attività di sviluppo, puoi imporre che tutti i commit siano collegati a un problema di jira.

E anche se non stai usando greeenhopper, potresti probabilmente creare un hook pre-commit che impone un commento di commit contenente un numero di riferimento per il rilevamento dei problemi.

Ciò dovrebbe probabilmente permetterti di raccogliere il changeset raccolto associato a un problema di jira, che mi sembra un'idea migliore.

Answer 4

Gli sviluppatori potrebbero creare un ramo per ogni modifica (non per ogni commit). Potrebbero impegnarsi tutte le volte che vogliono in questo ramo. Tuttavia, prima che le modifiche vengano unite nel trunk, è possibile applicare una revisione tra pari. Quindi il tuo trunk conterrà sempre e solo il codice peer review.

Puoi farlo tramite le autorizzazioni, quindi solo determinate persone possono impegnarsi nel trunk e possono verificare che il codice sia corretto prima di farlo.

Uso il controllo della versione da un po 'di tempo e penso che il lavoro nel modello dei rami (piuttosto che nel tronco) sia buono. I sistemi DVCS come git fanno un ulteriore passo avanti e sembrano funzionare bene per molte persone.

Answer 5

Un modo per farlo è con una regola di commit dei revisori sulla tua squadra. Cioè, gli sviluppatori non sono autorizzati a impegnare il proprio codice, devono convincere qualcun altro a impegnare il proprio codice per loro conto.

Ho lavorato su progetti come questo prima e funziona abbastanza bene. Il rovescio della medaglia è che con Subversion, ciò significa che il nome del revisore, non quello dello sviluppatore, appare nel registro. Con git, puoi conservare il nome dello sviluppatore e il revisore aggiunge una riga Signed-off-by: