1 – Tfs e customizzazione del process template
Nella prima parte abbiamo visto come è possibile scaricare in locale la definizione di un Process Template in modo da personalizzarlo con il Process Template Editor. In questo post vedremo alcune delle personalizzazioni possibili. Nella parte di metodologia si può semplicemente cambiare Nome e Descrizione del template
Figure 1: Personalizzare il nome e la descrizione del process template.
Tralasciamo per ora la sezione dei Work Item, che merita un approfondimento maggiore e dettagliato e osserviamo la sezione di “area & Iterations”. Qui possiamo impostare le aree e le iterazioni di default che verranno automaticamente generate quando creerete un nuovo Team Project basato su questo process template.
Figura 2: E’ possibile creare Aree ed Iterazioni di default che verranno automaticamente create con la creazione del Team Project
Il tab MS Project Mapping è molto particolare, perchè permette di definire come Microsoft Project mapperà i vari campi degli Work Item. Questa sezione è abbastanza “oscura” quando viene vista la prima volta, la spiegazione di cosa significhino i vari campi è definita in MSDN.
Figura 3: Esempio di mappatura dei campi per Microsoft Project relativa al process template di Microsoft Visual Studio Scrum 1.0
la prima colonna contiene il reference name (univoco) di un campo di un WorikITem. La seconda colonna invece rappresenta un campo di Project, tutti i campi custom sono mappati con il nome pjTaskText seguiti da un numero univoco, mentre alcuni campi sono predefiniti e ben conosciuti da Project, come ad esempio pjTaskName che identifica la colonna del TaskName. La terza colonna rappresenta un header da visualizzare in Project, se omesso viene usato il Field Name. L’ultima colonna invece rappresenta il tipo di unità da usare per il campo (utile per tutti quei campi dei work item che rappresentano una durata), ad esempio pjHour indica che il campo contiene un valore che rappresenta delle “ore”. Se selezionate una riga e premete il bottone “edit” troverete anche una checkbox che indica se il campo è in PublishOnly, valore che indica a Project di non fare mai refresh con il TFS ma solamente di propagare le modifiche. Quest’ultima impostazione serve per i campi che debbono essere editati esclusivamente da Project.
Alcune altre opzioni per il mapping con Project sono disponibili solamente editando direttamente il file XML, ma la personalizzazione più comune è comunque quella di mappare un nuovo campo dei Work Item, che può quindi essere fatta tranquillamente dall’editor appena visto.
La sezione Groups & Permissions permette invece di stabilire la security; per ogni gruppo infatti è possibile stabilire un livello di permesso di tipo “allow” o “Deny” per varie aree di security. Questa sezione è molto importante se nella vostra organizzazione avete dei requisiti particolari di sicurezza, oppure delle figure standard la cui combinazione di permessi non è tra quelle di base fornite da TFS. In questo modo alla creazione di un Team Project avrete i vostri gruppi di sicurezza già pronti e configurati.
Figura 4: Modifica dei permessi associati ai vari gruppi
Le due sezioni di Lab e Build permettono invece di includere nel Process Template i workflow di default per le build standard e le build di Lab Management. Grazie a workflow foundation è infatti molto semplice creare Workflow custom per soddisfare esigenze di build specifiche. Una volta che si è creato un workflow personalizzato, lo si può inserire direttamente nel process template in modo da averlo sempre disponibile.
Per includere un nuovo workflow lo si deve inserire nella sottocartella apposita del process template chiamata Build\Templates e poi aggiungere questo percorso nella sezione di Build dando una descrizione del file di build. Sia per il Lab che per la Build è anche possibile determinare per ogni gruppo di sicurezza i relativi permessi.
Figura 5: La definizione dei workflow delle build.
La sezione Source Control permette di scegliere le impostazioni di base del source control (check-out esclusivo e get latest automatico durante il check-out), e soprattutto permette di definire tutte le possibili Check-In note. Anche in questo caso, se nel vostro processo utilizzate una particolare nomenclatura, oppure avete una specifica review o informazione che solitamente volete associare al check-in, potete rimuovere/aggiungere check-in notes con pochi click.
Figura 6: Impostare le check-in note.
Infine, la sezione Portal e Reports, includono rispettivamente tutti i documenti di base che andranno inseriti nel portale sharepoint e tutti i report di base che andranno invece inseriti nel Reporting Services di Sql Server.
Fgiura 7: I documenti di base del portale sono semplicemente inseriti in una cartella della definizione del Process Template ed inclusi con l’editor.
Anche in questo caso se avete fatto dei report custom, oppure se avete una serie di documenti standard che usate normalmente nel vostro processo è possibile includerlo nel Process Template, in modo da averli automaticamente inseriti nel portale Sharepoint.
alk.