In un precedente post ho mostrato come sia semplice aggiornare TFS passando ad esempio dalla versione 2010 alla versione 2012 su una differente macchina. Una delle domande che vengono poste più frequentemente è: “Cosa succede durante l’aggiornamento del process template se io lo ho personalizzato?”

Se non avete mai personalizzato il process template, e/o non conoscete nulla dell’argomento, potete consultare una serie di post nel mio blog di Ugi.NET

La buona notizia è che la personalizzazione del process template non previene assolutamente l’aggiornamento automatico del template passando ad una versione successiva, a meno di non avere personalizzato eccessivamente. Ad esempio aggiungendo qualche campo al vostro process template, troverete che questa personalizzazione rimarrà invariata anche dopo l’aggiornamento.

In questa immagine si può notare come il nuovo campo sia rimasto anche dopo l’aggiornamento alla versione TFS 2012 e soprattutto dopo l’aggiornamento automatico del process template. Esistono però personalizzazioni che bloccano sicuramente l’aggiornamento automatico del template (e quindi dopo avere aggiornato TFS alla nuova versione, per abilitare le nuove funzionalità è necessario procedere manualmente).

Ecco le personalizzazioni che bloccano l’aggiornamento

1) Inserire un nuovo field il cui nome è usato dalla versione aggiornata ma ha tipo differente. Date quindi sempre nomi al campo che iniziano con il nome della vostra ditta, es nablasoft.MyPriority e non incorrerete in problemi.

2) Aggiungere un nuovo tipo di Work Item che diventa un nome riservato in una versione successiva. Es introducete il Work Item Type “Feature” e nella nuova versione di TFS è stato introdotto un Work Item Type con lo stesso nome. Per evitare questo ogni nuovo tipo di Work Item dovrebbe avere un nome univoco, magari usate un prefisso o suffisso tipo Feature_C (dove _C sta per Custom).

3) Togliere stati o transizioni oppure aggiungere restrizioni tra le transizioni. Questo tipo di modifiche può impedire il funzionamento di future funzionalità delle taskboard ad esempio.

4) Cambiare troppo radicalmente il posizionamento dei controlli nell’editor, perchè rende impossibile al processo di aggiornamento di capire dove mettere i nuovi campi.

1. Per I punti 3 e 4 purtroppo non esistono regole scritte nella pietra, anche perchè è impossibile prevedere le nuove funzionalità su quali stati e transizioni saranno basate, per cui sappiate che editare gli stati del work item potrebbe generare  problemi.

Ricordo comunque che questo significa che dopo l’aggiornamento alla nuova versione di TFS, alcune nuove funzionalità potrebbero non essere abilitate, l’aggiornamento viene comunque fatto, ed è sempre possibile procedere all’aggiornamento manuale del processo.

Tra i consigli che posso dare per la personalizzazione del template, il più importante è senza dubbio quello di scaricare il process template in locale e metterlo sotto controllo di codice sorgente, in modo da poter sempre vedere quali sono le esatte modifiche che si sono effettuate. In questo modo è possibile procedere agli upgrade manuali sapendo esattamente dove si è intervenuto, e tutto il processo risulta più semplice.

Come ultima nota, se avete creato un proprio processo partendo da uno di quelli base ed avete cambiato nome, questo non previene l’aggiornamento atuomatico, dato che la procedura controlla comunque la struttura dei file XML. Anche se il vostro processo si chiama in modo differente, ma è basato ad esempio sul MSF for agile a cui avete aggiunto due campi, quando chiedete l’aggiornamento vi verrà rilevato comunque come MSF For Agile e verrà aggiornato.

Gian Maria.