Quanto è importante l'integrazione del controllo della versione con il software di tracciamento dei bug

Question

Attualmente usiamo FogBugz per problemi di tracciamento e lo abbiamo trovato corretto. Sto cercando qualcos'altro che possa consentire agli utenti finali di rintracciare i loro casi insieme a noi. E qualcosa che funziona davvero bene con la posta elettronica. Ho trovato alcune alternative che supportano queste funzionalità ma non si integrano con il controllo della versione. Abbiamo tutti gli hook SVN in nebbia bugz e li usiamo - ma non li ho trovati davvero utili. Qualcuno ha trovato una buona ragione per aver bisogno dell'integrazione del controllo della versione con i bug tracker?

Answer 1

Chiaramente, questo tipo di integrazione non è qualcosa di essenziale per il funzionamento del software. Con un po 'di disciplina, ogni check-in può essere accompagnato manualmente da un numero di bug e ad ogni risoluzione di bug può essere aggiunto manualmente un tag di controllo della versione.

A parità di altre condizioni, personalmente preferirò sempre l'automazione rispetto alla "disciplina degli utenti", perché questi ultimi prima o poi vi lasceranno di tanto in tanto. Non perché gli utenti siano malevoli o incompetenti, ma semplicemente perché le persone non possono essere sempre al 100%.

Answer 2

È una domanda sulla dimensione del codice e su quanti bug è necessario tenere traccia.

Ed è anche molto utile per i non codificatori nell'organizzazione, ovvero i gestori e l'assistenza clienti. Possono trovare le risposte a domande come "Quando e dove è stato risolto questo bug" ...

Answer 3

Penso che sia utile distinguere tra bug rilevati all'interno dell'organizzazione di sviluppo, ad es. dalla revisione del codice peer, contro i bug riscontrati da un gruppo di test esterno all'organizzazione di sviluppo.

Il (piccolo) vantaggio per il controllo della versione coordinata con errori rilevati da un gruppo di test esterno potrebbe essere per riferimento storico.

Il vantaggio maggiore consiste nel coordinare i bug rilevati tramite peer code review con controllo della versione: in questo modo è possibile certificare che tutto il codice è privo di bug peer review prima di rilasciarlo a gruppi di test esterni; un requisito comune.

FYI, Collaboratore di codice da SmartBear, Inc. gestisce questo bene.

Answer 4

Trovo molto utile l'integrazione di SVN con TRAC. Tramite gli hook SVN, il commit al repository con un numero di ticket inserisce un commento sul ticket con un collegamento a una bella rappresentazione HTML visiva del numero di revisione, mostrando inserimenti, eliminazioni e diff.

Come supervisore di un piccolo gruppo di programmatori, trovo questo come uno strumento utile per eseguire revisioni del codice, così posso verificare che il commit risolva veramente il problema associato. Non definirei questa integrazione essenziale, ma è stato un bel extra gratuito sul mio tracker dei problemi che ho imparato ad amare.

Answer 5

È assolutamente fondamentale per noi.

Qui è un tipico commit per uno dei nostri progetti (campione):

Make sure filedes is cleared in child list prior to reallocating 

When p->child-filedes is > 0, the child list is active and can not 
be collected. 

[ Impact: Closes bug 123457 ] 

Nota il [Impact:] linea, che potrebbe anche essere "racconta-To", "causato" o un qualsiasi numero di altre cose.

Questo ci consente di utilizzare greps semplici e script automatici che consentono a chi si impegna a chiudere automaticamente o addirittura a riaprire un bug.

Anche se in genere utilizziamo Git e Mercurial, questo tipo di hook funzionerebbe su (quasi) qualsiasi VCS, specialmente quelli proprietari che non dispongono di alcun plug-in modulare di cui avete bisogno.

Se pensi al tuo sistema di bug come a un'altra parte del tuo VCS, è davvero facile vedere come dipendono l'uno dall'altro.

Altri elementi, come ad esempio il recupero di patch inviati con bug, sono possibili anche.

Answer 6

Ho trovato che l'integrazione del controllo della versione è estremamente utile per gestire e gestire più versioni (stabile, trunk di sviluppo, ecc.) Di un progetto.

L'utilizzo dell'integrazione del controllo della versione e un po 'di disciplina dai codificatori per fare riferimento ai ticket dei bug in commit (o alcuni hook di pre-commit per richiedere forzatamente i riferimenti ai ticket) ci ha permesso di generare rapidamente e facilmente elenchi di changeset necessari per correggi qualsiasi bug dato. Questo è strumentale quando si uniscono le correzioni in vari rami stabili del codice.

Non è una necessità, ma sicuramente rende la vita più facile per la gestione dei rilasci.

Ho usato SVN + Trac e il prodotto Jira di Atlassian con il plug-in SVN Fisheye e ho trovato entrambi gli strumenti molto buoni. Trac sembra essere un po 'più semplice, ma molto facile da usare. Jira, a mio parere, aveva un aspetto più gradevole e un bel po 'di campane e fischietti, ma a volte era quasi troppo.