DCVS e database di bug

Naviga le tue risposte
4

Sto pensando di implementare la seguente politica e vorrei eseguirla dalla comunità prima di implementarla:

Tutti i commit mercurial devono avere un id di bug corrispondente al nostro database di segnalazione bug.

Tutti i commit immediatamente precedenti a un push per una nuova funzione devono avere un bug id (è una nuova funzione ma l'id è ancora un "bug id" nel database)

Questo farà molte cose. Innanzitutto, assicurerà che una voce sia sempre inserita nel database dei bug per tutte le modifiche al codice. In secondo luogo, fornirà un diff di ogni modifica apportata per ciascuna correzione di bug. Ciò semplificherebbe anche il commento nei commit mercurial e metterà la maggior parte dei dettagli sul commit nel bug report.

Conosci qualche motivo per cui questa sarebbe una cattiva idea? Inoltre, pensi che dovrei apportare alcune aggiunte a questa politica?

    
posta Jonathan Henson 07.03.2012 - 18:47
fonte

5 risposte

5

Sicuramente non vuoi applicare questa norma su all commit . Uno dei vantaggi di DVCS è che gli sviluppatori possono impegnarsi e promuovere modifiche alle filiali private in qualsiasi momento. È una politica ragionevole per il commit del codice di produzione nel repository centrale.

    
risposta data 07.03.2012 - 19:21
fonte
1

Lo facciamo dove lavoro (in teoria).

È davvero molto utile quando le persone lo fanno nel modo giusto, in quanto puoi entrare nei casi del nostro particolare bug-tracker di scelta e vedere che stai ricevendo i giusti changeset per una particolare release basata sugli ID dei casi le funzionalità che stai aggiungendo. Il tuo punto sul tenere i commenti sul caso è un altro vantaggio, poiché nella mia esperienza nessuno leggerà i messaggi di commit .

Tuttavia, è un problema quando le persone mettono l'ID caso sbagliato su o semplicemente non disturbano , quindi direi se hai intenzione di assicurati di avere un repository di staging in cui puoi modificare l'ID del caso prima di inserirlo nel bagagliaio e aggiungere un criterio al terminale remoto per rifiutare i changeset senza un ID caso su di essi.

    
risposta data 07.03.2012 - 19:03
fonte
1
  1. La documentazione tutte le modifiche in forma di ticket è, in comune, di buon stile
  2. Link diretti I changeset dei biglietti sono buoni

Ma

  1. Alcuni changeset potrebbero essere indirettamente correlati al problema (1-st CS - modifiche per ticket, 2-nd + - correzioni per CS 1)
  2. La cronologia piana con solo messaggi di commit non fornisce un'interfaccia piacevole per il filtro dal lato VCS
    3. Il flusso di lavoro di
  3. Branch-per-feature nasconde gli effetti collaterali di 1 e 2 e rende marcatura tutti i changeset obsoleti anche dal lato track-tracker - a cui si fa riferimento forse solo il primo e l'ultimo commit
risposta data 07.03.2012 - 20:12
fonte
0

Le persone non guardano nei database dei bug per vedere le differenze di codice per i bug. Guardano nel controllo della versione. Pertanto, ha senso richiedere un bug id per l'ultimo commit che corregge un bug, in modo da poter prendere nota nel bug tracker e identificare quali sono le correzioni dei bug di build, ma ogni singolo commit è eccessivo.

Se le persone commettono funzionalità che non vuoi, hai un altro problema e probabilmente hai bisogno di una sorta di flusso di lavoro del gatekeeper. Ti consiglio vivamente di esaminare soluzioni più integrate come forno o bitbucket.

    
risposta data 07.03.2012 - 20:13
fonte
-3

Più ostacoli mi impedisci di commettere, meno spesso mi impegnerò. Ciò sconfigge davvero il punto di un DVCS.

Stai davvero cercando di risolvere un sintomo con questo approccio piuttosto che cercare di risolvere la causa principale. Hai un team di sviluppatori che:

  • Non capisco il valore del bug tracker;
  • Non sembra comunicare molto bene e ripeti il lavoro che altri sviluppatori hanno già fatto;
  • Veer off-task e codice di scrittura che non è stato discusso e non è stato autorizzato.

potresti far rispettare questa politica. Tuttavia, se gli sviluppatori sono già disfunzionali, cosa otterrà veramente questa politica? Ti verrà improvvisamente assegnato un team concentrato e comunicativo che mantiene un eccellente set di segnalazioni di bug?

No. Ti darà un sacco di correzioni di bug verificate contro il bug report sbagliato.

Devi affrontare i problemi del tuo team gestendoli . Mostra loro come si stanno calpestando l'un l'altro. Tieni riunioni giornaliere stand-alone in modo che Bob possa dire al team che sta correggendo il bug X in modo che Dave non inizi a lavorare sulla stessa cosa. Spiega il valore del bug tracker. Se i tuoi sviluppatori vengono a vedere che quello che stai cercando di ottenere è una buona cosa lo faranno automaticamente.

    
risposta data 07.03.2012 - 18:58
fonte

Leggi altre domande sui tag

Cosa sono meglio i datastore grafici di altri datastore e perché? Forzare l'accesso secondario di root aggregato attraverso la sola radice aggregata