Processo raccomandato per le revisioni del codice con mercurial

Di recente abbiamo analizzato quasi esattamente la stessa cosa nella mia azienda. Ecco cosa abbiamo fatto:

• Conserviamo una copia definitiva centrale di tutti i nostri repository su un server. Quando gli sviluppatori vogliono "controllare" il codice, vanno su questo server e clonano dagli archivi lì. Allo stesso modo, quando il ciclo di sviluppo è completo, il codice viene inserito anche nel repository appropriato.

• Separiamo i repository stable dai repository di sviluppo . Richiediamo che il codice venga rivisto prima di essere inserito in un repository stabile. (Ciò è significativo perché richiediamo anche che i nostri repository stabili contengano il codice attualmente in esecuzione in produzione, difforme solo dalle promozioni in attesa di codice.)

Per applicare la revisione del codice, abbiamo scritto un hook pretxnchangegroup (documentato in HG Book ). Sfruttiamo il fatto che quando questo hook viene eseguito, può vedere il repository come se le modifiche al codice fossero permanenti, ma ci dava anche la possibilità di impedire il push. Fondamentalmente, il processo è il seguente:

1. Lo sviluppatore avvia una push nel repository stabile (sì, questo è davvero il primo passo)
2. L'hook esegue e acquisisce un elenco di tutti i changeset inclusi nella transazione (eseguendo il registro HG). Quindi esegue una query su un database che abbiamo creato per verificare se tali changeset sono stati inclusi in una revisione del codice. (La tabella corrisponde all'hash di un changeset con un ID di revisione del codice).
   • Se è la prima volta che uno di questi changeset è stato visto, creiamo un nuovo Code Review (usando la riga di comando Code Collaborator), e quindi registriamo questi changeset nel database con l'ID della revisione del codice.
   • Se abbiamo visto alcuni (ma non tutti) dei changeset, eseguiamo il comando (Code Collaborator) per collegare i nuovi changeset alla revisione esistente e registrare questi nuovi changeset nel database.
   • Se tutte le modifiche sono state trovate nel database (cioè sono state tutte aggiunte alla revisione del codice), quindi verifichiamo che lo stato della revisione del codice sia Completato. Tuttavia, se sono presenti nuovi changeset (o la revisione del codice non è completa), l'hook si chiude con un codice di stato diverso da zero (facendo in modo che Mercurial esegua il rollback della transazione) e restituisca un messaggio amichevole su Errore standard che spiega allo sviluppatore che la revisione del codice deve essere completata.

In sostanza, questo fornisce allo sviluppatore un processo abbastanza snello (tutto ciò che devono fare è un hg push) e automatizza completamente la creazione della revisione del codice (e il caricamento di altri file modificati nella revisione), assicurando che tutto il codice viene revisionato.

Nota: questo è un processo abbastanza semplice (e relativamente nuovo per noi), quindi potrebbe non funzionare per tutti, e potrebbero esserci alcuni bug di progettazione che non abbiamo ancora eseguito. Ma finora, ha funzionato abbastanza bene.

Dipende da come hai la struttura del tuo repository e cosa stai cercando di realizzare. Preferiamo fare recensioni di "pre-commit", che nel mondo di DVCS significa davvero "pre-push". Le DVCS sono più belle in questo ambiente (se confrontate con le tradizionali SCM) perché hanno funzionalità integrate per salvare le modifiche locali e ripristinare lo spazio di lavoro in modo da poter lavorare su qualcos'altro.

Se si desidera eseguire revisioni post-push, il flusso di lavoro ideale dipende in larga misura dalla struttura del proprio repository. Ad esempio, assumiamo una struttura del repository simile a quella discussa in questo articolo sui layout del repository Git . In questo caso, potresti voler esaminare le modifiche che vengono unite in develop . I singoli commit su feature branch potrebbero non avere senso revisionare. Ovviamente anche hotfixes deve essere rivisto insieme all'unione in master .

Se invece si dispone di un singolo ramo di integrazione in cui le persone effettuano il check-in direttamente, è opportuno rivedere tutti i push su quel ramo. Probabilmente è leggermente meno efficiente, ma potrebbe comunque funzionare. In questo ambiente, dovresti assicurarti che tutte le modifiche che sono state sottoposte a push vengano riesaminate prima di tagliare una versione. Questo può essere più complicato.

Per quanto riguarda b) l'unica cosa che suggerirei è inviare via email il supporto SmartBear ([email protected]) direttamente. Noi (sì, lavoro per SmartBear) saremo lieti di aiutarti a risolvere i tuoi problemi relativi ai percorsi, ma non ci sono abbastanza informazioni in questa domanda per risolvere il tuo problema. Il processo normale è semplicemente eseguire l'installer e tutto funziona correttamente. Apparentemente qualcosa è andato storto in quel processo.