Precedenti post sulla personalizzazione Work Item in TFS
1 – Tfs e customizzazione del process template
2 – Customizzare il Process Template, le basi
3 – Customizzare il process Template, aggiungere un campo ad un Work Item
4 – Customizzare il process template, regole per i campi aggiuntivi dei WI
5 – Personalizzare i Work Item di TFS, ancora qualche regola interessante
6 – Stati e transizioni
7 – Approfondiamo stati e transizioni
Post su personalizzazione VSTS
1 - Personalizzare il process template in VSTS
2 - Process template Ereditati in VSTS
3 – Aggiungere ad un Work Item un campo esistente in un altro template
Nel precedente articolo è stata descritta la procedura per aggiungere ad un Work Item Type un campo già esistente in VSTS. In questo post vedremo invece come aggiungere un campo completamente nuovo, che non è quindi pre-esistente in VSTS. La procedura seguita è molto simile alla precedente, è sufficiente infatti andare nel layout del tipo di Work Item che si vuole modificare ed aggiungere un nuovo Field nella posizione desiderata.
A questo punto invece di usare un campo esistente è sufficiente scegliere di creare un nuovo tipo di campo scegliendo come primo passo la tipologia di dato che si vuole utilizzare.
Come si può oservare, è possibile scegliere tra vari tipi di dato: si parte dai tipi testuali (singola linea e multipla) poi vi sono i classici tipi Data, boolean, numerici ed anche la possibilità di utilizzare Picklist. A differenza della personalizzazione effettuabile on-premise, non è possibile utilizzare tutto il set di regole di TFS (ad esempio ALLOWEDVALUES), ma si è limitati da ciò che l’interfaccia utente offre. La flessibilità è comunque sufficiente per la maggior parte delle personalizzazioni più comuni e le limitazioni, come già detto in precedenza, garantiscono che la personalizzazione rimanga nei “binari” predeterminati, cosi da non avere problemi al momento di eventuali aggiornamenti.
Supponiamo ad esempio di volere inserire un campo booleano nel bug per indicare se il bug è stato segnalato direttamente dal cliente oppure se è stato trovato da un team di test interno. In questo caso è sufficiente specificare il nome del campo, una descrizione e specificare boolean come tipo.
Una volta aggiunto il nuovo campo, quest’ultimo è subito visibile editando o creando un nuovo bug e si può immediatamente utilizzarlo.
L’interfaccia utente viene generata dinamicamente sulla base del tipo di campo in modo da aiutare l’utente nella compilazione. Se ad esempio il campo è di tipo booleano come nel nostro esempio, viene utilizzata una checkbox, se si utilizza un campo text il controllo sarà una normale textbox e cosi via.
Grazie alle PickList è supportata la scelta multipla, si può ad esempio aggiungere un campo Reproducibility che indica la riproducibilità del bug.
In questo caso nel tab Options è possibile specificare se il campo è o meno obbligatorio, e si può specificare anche il valore iniziale di default se necessario.
Nell’interfaccia utente il nuovo campo verrà rappresentato con una ComboBox con all’interno i campi specificati nel template. Questo tipo di campo è spesso il più richiesto come personalizzazione, perché è uso comune nei vari team di andare a dettagliare i Work Item con delle informazioni specifiche del proprio processo. Sebbene l’uso dei Tag possa in molti casi sopperire a molte delle richieste, avere la possibilità di inserire campi specifici a scelta multipla è una funzionalità tra le più utili.
Purtroppo a differenza delle personalizzazioni che possono essere effettuate on-premise non esiste un concetto analogo alla GLOBAL LIST e quindi se abbiamo più tipologie di campi è necessario mantenere tutte le varie picking list manualmente.
In caso di rimozione di uno dei valori della picking list, i Work Items che hanno impostato il valore rimosso sono ancora validi, ma la prima volta che verranno editati verrà forzato il cambiamento ad uno dei valori ammessi. Ad esempio togliendo il valore Sometimes ed aggiungendo il valore Unknown, se apriamo un Work Item che ha il valore Sometimes impostato per il campo, quest’ultimo verrà marcato in giallo, perché fallisce la validazione ed è necessario quindi cambiarlo.
Non esiste per ora la possibilità (come invece esiste per la versione on-premise) di permettere il mantenimento del valore anche se non più presente nella lista dei valori ammessi.
Il nuovo campo può in ogni momento essere cancellato dalla definizione, questo non cancella fisicamente i dati dal Database, ma semplicemente impedisce di visualizzarne il valore nell’interfaccia utente. Questo è infatti il messaggio di warning che viene dato quando si rimuove un campo custom dall’interfaccia utente.
La riprova che i dati siano ancora effettivamente nel database si ha accedendo al Work Item tramite le API. Se infatti si rimuove il campo Reproducibility dal tipo Bug e poi si recupera un work item di tipo Bug con le REST API si può notare che il valore del campo è ancora li.
Naturalmente è possibile volere rimuovere completamente il nuovo campo, cancellando anche tutti i dati in tutti i work item in cui il campo era stato valorizzato. Per fare questo è necessario prima rimuoverlo precedentemente da tutti i layout di interfaccia e successivamente disassociarlo anche dai Work Item che lo hanno collegato.
Come si può vedere dalla figura precedente è necessario selezionare il tab dei tipi di Work Item, selezionare la visualizzazione dei Field ed infine localizzare il campo che si vuole rimuovere e scegliere la voce di menù “Remove” dal menù contestuale. Anche in questo caso il sistema avverte che in realtà nessun dato è viene realmente rimosso, e si può aggiungere nuovamente lo stesso campo e ritrovare cosi tutti i dati in tutti i Work Item che avevano popolato quel campo. Sempre con le REST API potete verificare che il valore del campo è ancora presente in tutti i Work Item preesistenti anche dopo averlo rimosso dal tipo.
Una volta che il campo non è più referenziato da nessun tipo di Work Item è possibile andare nel tab di gestione globale dei campi, selezionare il campo custom e distruggerlo definitivamente.
Come si può vedere dalla figura precedente, il campo Reproducibility non ha l’icona a sinistra che indica un campo ereditato dal template padre, per cui può essere rimosso definitivamente con il comando Destroy.
Questa volta il sistema avverte che l’operazione non è reversibile e che anche tutti i dati storici verranno cancellati.
Naturalmente tutti i campi custom creati possono essere utilizzati nelle query di TFS senza problema alcuno, ecco ad esempio come definire una query che ci estrae tutti i bug segnalati dal cliente che sono ancora aperti.
I campi custom possono anche essere utilizzati nella definizione degli alert, si può ad esempio volere un alert ogni volta che un nuovo bug segnalato dal cliente è stato inserito nel sistema.
Da questo semplice articolo si può apprezzare come aggiungere un campo ad un tipo di Work Item sia una operazione decisamente semplice e sicuramente molto più alla portata di tutti rispetto all’editing del process template standard.
Nel prossimo articolo verrà esaminato invece come creare un nuovo tipo di Work Item.
Gian Maria.