Integrazione continua: come legare le build a requisiti / attività / bug?

Question

Come rispondi alle seguenti domande di manager, tester e altre persone del tuo team:

In quale build è stato corretto il bug # 829? Quali attività sono state completate nella nostra attuale build di test?

In poche parole, come si può ottenere la tracciabilità delle proprie esigenze, attività e bug direttamente dalla loro segnalazione alla distribuzione? Quali processi, strumenti e tecniche stai usando per raggiungere questo obiettivo?

Answer 1

Utilizziamo TRAC con SVN nella nostra azienda ed esegui build di rolling giornaliere su DEV / STAGING & amp; Ambienti STABILI con distribuzioni pianificate regolari (una volta al mese ... ish) in un ambiente di PRODUZIONE.

Quando viene segnalato un bug, viene inserito in TRAC e gli viene assegnato un numero di Ticket (ad es. # 1001)

Quando il bug è stato corretto, il codice viene ricontrollato in SVN con il numero del biglietto (# 1001) nelle note del check-in SVN.

Lo sviluppatore prende nota del numero del set di modifiche SVN (ad es. [5000]) e apre l'interfaccia utente web di TRAC. Alla chiusura del biglietto, inseriscono il numero del changeset nelle note del biglietto.

In questo modo, il check-in SVN fa riferimento al ticket ... e il ticket fa riferimento al check-in SVN.

Le nostre build giornaliere vengono quindi eseguite su un changeset SVN (ad es. build di oggi è tutto fino al changeset [5050]) e una nota è fatta di questo nel nostro avviso di distribuzione.

Deployed On   |  Environment            | Changeset
--------------+-------------------------+--------------------------
10-01-2008    |  DEV                    | 5100
10-01-2008    |  STAGING                | 5080
10-01-2008    |  STABLE                 | 5050
01-01-2008    |  PRODUCTION             | 5000

In questo modo i tester durante la revisione delle correzioni per i test sanno dal changeset nei commenti del ticket se la build che stanno guardando include la correzione.

Answer 2

Usiamo TFS insieme a TeamCity di JetBrains per CI.

Quando si associano i check-in alle attività, la nostra politica di check-in personalizzata antepone le attività e i bug associati con i loro ID e titoli ai commenti sul check-in.

Questi commenti vengono quindi utilizzati per generare le note di rilascio, che vengono generate automaticamente per ogni build.

Answer 3

Stiamo tag il check-in di controllo del codice sorgente con il numero di difetto che è stato corretto o il numero di miglioramento che è stato implementato.

Recuperando il registro del check-in tra due build, è possibile determinare cosa è stato implementato o corretto.

Answer 4

Utilizziamo un servizio SVN gestito chiamato Beanstalk ( http://www.beanstalkapp.com/ ) che ti consente di collegarti facilmente con una serie di sistemi di gestione Bug / Feature. Nel nostro caso, utilizziamo FogBugz di Fog Creek per questo scopo. SVN / Beanstalk ti consente di prendere appunti quando esegui il check in di una build che, a sua volta, influenzerà lo stato di uno o più FogBugz casi.

Sul lato client, utilizziamo Tortoise SVN e Visual SVN per gestire l'interazione tra il client locale e il server Beanstalk SVN (Tortoise fornisce il servizio effettivo, Visual SVN fornisce l'integrazione tra Tortoise SVN e MS Visual Studio).

Consiglio vivamente sia i servizi sia il client Tortoise / Visual SVN.

Answer 5

Stiamo usando Fogbugz che ha l'integrazione di sovversione integrata. Fondamentalmente c'è un plugin per Fogbugz che controlla i check-in SVN in background. Quindi, se fornisci un ID caso Fogbugz al momento del check-in, viene automaticamente collegato a questo check-in.

Per quanto ne so non hai bisogno di alcuna applicazione speciale (come Beanstalk per esempio).

Il contrario è un po 'complicato. Nella nostra azienda esiste una convenzione secondo cui per ogni build (futura o passata) esiste un "rilascio" a Fogbugz. Se si corregge un bug o si implementa una funzione, si assegna il caso alla versione corretta.

Quindi è abbastanza facile ottenere un elenco di tutte le funzionalità implementate di build X.