Integrazione continua: come legare le build a requisiti / attività / bug?
-
04-07-2019 - |
Domanda
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?
Soluzione
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.
Altri suggerimenti
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.
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.
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.
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.