Uno dei vantaggi nell’uso di TFS è la possibilità di associare uno o più Work Item ad un Check-in in modo da aumentare la tracciabilità del codice. Una delle prime domande che gli utenti fanno quando si usa il processo Scrum 1.0 è il fatto che durante un check-in si può solamente associare ad un Bug e non ad esempio impostare direttamente il bug come “Done” (“Resolve”)
Figura 1: Durante un check-in posso solamente associare ad un bug, ma non metterlo nello stato Done
Questo processo è sicuramente il più giusto, perché in Scrum dovreste dopo il check-in, andare nel work item e spostarlo nello stato “done” associando anche il numero delle ore utilizzate per la sua correzione. Supponiamo però di voler modificare questo comportamento, permettendo di “risolvere” il bug durante un check-in, quello che dovete fare è scaricare in locale il process template, localizzare il file bug.xml ed aggiungere una azione nella transizione corrispondente.
Figura 2: Aggiungendo l’azione Microsoft.VSTS.Actions.Checkin alla transizione dallo stato commited to Done abilitiamo la risoluzione del bug
L’azione inserita indica a TFS che si può passare dallo stato “committed” allo stato “done” durante un check-in, ed è proprio quello di cui abbiamo bisogno. Purtroppo se utilizzate l’editor dei power tools, sembra che ci sia un bug per cui anche aggiungendo la Azione dal designer grafico, la modifica non viene correttamente salvata nel file, per cui è necessario sporcarsi le mani un pochino con un po di XML (l’operazione è comunque banale).
Ora basta uploadare questo process template, creare un nuovo team project basato sul nuovo template, e ora magicamente potete risolvere un bug durante un check-in.
Figura 3: Ora è possibile associare il workItem al Check-in e risolvere il bug allo stesso tempo (scatenando la transazione da committed a done)
Ora vi chiederete, ma se il Process Template Editor non salva le actions, come posso modificare la definizione di bug su un progetto già esistente? La soluzione è sporcarsi le mani con i tool a riga di comando. Fase uno, esportate in XML la definizione del bug da un TEam Project
witadmin exportwitd /collection:http://localhost:8080/tfs/defaultCollection /p:TestAgile /n:Bug /f:bug.xml
Come potete vedere l’opzione /p permette di specificare un team project e con /n specificate il nome della tipologia di Work Item che volete esportare. Fase due, ora potete editare il file bug.xml aggiungendo la action per il check-in come visto in precedenza. Fase tre aggiornate la definizione di bug direttamente nel progetto.
witadmin importwitd /collection:http://localhost:8080/tfs/defaultCollection /p:TestAgile /f:bug.xml
Ed il gioco è fatto, ora nel check-in avete anche l’opzione resolve :).
Happy TFS.
Alk.
Tags: TFS Scrum