Guest post - Migrare da Team Foundation Server a Team Foundation Service (e viceversa)

Questo guest post è stato scritto da Gian Maria Ricci, MVP Visual Studio ALM.

Con l’annuncio dell’RTM della versione “in the cloud” di TFS, chiamata Team Foundation Service l’opzione di migrare da una versione on-premise alla versione online è diventata decisamente allettante. Le ragioni per migrare alla versione nella cloud sono molte soprattutto per piccoli team che già usano Team Foundation Server Express 2012 (con licenza gratuita fino a cinque utenti). Passare da un Team Foundation Server express a Team Foundation Service permette infatti di avere:

• Costo zero fino a 5 utenti
• High availability e backup a costo zero
• Upgrade continuo ad ogni sprint (3 settimane)
• Accessibile ovunque in Https
• Agile planning tools (non disponibili per TFS Express on premise).

Chi attualmente sta usando Team Foundation Server 2010 o il 2012 Express e vuole passare alla versione su Azure deve quindi pianificare la migrazione considerando le alternative disponibili ad oggi.

Migrazione rapida con perdita di history

L’opzione più rapida, ma che non permette di mantenere la history è, per ogni team project che si vuole migrare, creare un team project in TF Service, mappare il source control con un workspace, copiare la versione più recente dei sorgenti e fare check-in. A questo punto basta aprire le solution, aggiornare il binding al nuovo server ed avete con pochi click migrato i file sorgenti, chiaramente non mantenendo la history.

La stessa tecnica può essere usata per migrare i work item, basta infatti creare una query che recupera tutti i work item di quello specifico team project, aprirla in Excel caricando tutti campi dei Work Item selezionando tutte le colonne disponibili, a questo punto basta aprire un'altra istanza di Excel, connetterla a TF Service ed incollare tutti i dati dalla prima istanza, a questo punto un publish salverà tutti i dati in TF Service. Anche in questo caso non vi portate dietro la history e non vi portate dietro i campi di tipo HTML e nemmeno gli attachment dei work item.

Per chi volesse procedere per questa strada, ecco le operazioni da fare in maggiore dettaglio:

Prima di tutto create una query per recuperare tutti i Work Item senza imporre nessun filtro, in questo modo potrete caricare tutto in Excel in maniera facile.

A questo punto selezionate tutte le colonne che volete importare, ad esempio potete aggiungere tutte le colonne disponibili per tutti i work item. In questo punto fate attenzione perché la versione di TFS che è presente su TF Service viene costantemente aggiornata, per cui è possibile che per il vostro Process Template il processo di destinazione abbia più campi.

Ora dovete assicurarvi che nel Team Foundation Service sia presente il nuovo progetto di destinazione creato con lo stesso identico Team Process Template. Nel TP di destinazione create le stesse iterazioni ed aggiungete i LiveId di tutti gli utenti corrispondenti al vostro sistema on –premise Naguralmente gli utenti non possono essere gli stessi dato che nel vostro sistema avrete normali utenti di windows / Dominio, mentre in TF Service le utenze sono identificate dalle E-Mail legate al LiveID. A questo aprite un nuovo Excel e connettetevi al Team Project di destinazione senza caricare nulla, visualizzate tutte le colonne e fate in modo che l’ordine sia lo stesso dell’excel su cui avete caricato i work item del vostro progetto on-premise e poi fate copia ed incolla. In questa fase è necessario assicurarsi che le colonne dell’excel sorgente siano le stesse identiche di quelle di destinazione, ad esempio nel template scrum è presente una colonna in più chiamata Tags.

A questo punto potete fare publish e verificare che tutto sia stato salvato correttamente.

I problemi dello spostamento massivo con Excel sono però numerosi: prima di tutto tutti i campi HTML non manterranno la formattazione HTML, gli utenti non saranno gli stessi, (per cui se volete mantenere l’assegnazione attuale dei work item dovete farvi una macro o manualmente correggere gli utenti del sistema sorgente con quelli di destinazione). Il campo Created-By sarà automaticamente popolato dall’utente con cui vi siete connessi (perché non potete da Excel impersonare un'altra persona e far si che il bug risulti creato o modificato da altri), infine gli attachment non saranno preservati.

Questa soluzione è dunque poco efficace, ma vi permette in pochi minuti di spostare i vostri dati su TF Service. In questo scenario è fortemente consigliato tenere attivo per un po il vostro TF Server on-premise e comunque fare un detach e backup della vostra project collection, in modo che per ogni evenienza voi manuteniate tutti i dati storici dei vostri progetti e possiate restorarli se necessario.

Migrazione con Integration platform

Chiaramente il mantenimento della history dei work item e del source control è un opzione desiderabile in molti casi e dunque la migrazione rapida mostrata non è una soluzione accettabile. A data odierna la migliore soluzione è usare l’Integration Platform, un progetto open source gestito dai TFS Rangers che permette di gestire la sincronia e le migrazioni da e verso Team Foundation Server ed altri sistemi. Il primo passo è scaricare ed installare la Integration Platform dal Visual Studio Gallery all’indirizzo http://visualstudiogallery.msdn.microsoft.com/eb77e739-c98c-4e36-9ead-fa115b27fefe e procedere all’installazione.

La maggior parte dei dettagli sul funzionamento dell’Integration Platform si trovano nel corrispondente progetto su Codeplex (http://tfsintegration.codeplex.com/), ma potete trovare informazioni anche nel blog dei Rangers, ad esempio qui http://blogs.msdn.com/b/willy-peter_schaub/archive/2011/05/11/tfs-integration-tools-where-does-one-start-part-1.aspx. Esiste anche un articolo dedicato su MSDN Italia scritto da Matteo a Questo indirizzo http://msdn.microsoft.com/it-it/library/jj191716.aspx

Una volta installata la Integration Platform si può procedere alla migrazione del source control e dei Work Item impostando una configurazione di migrazione. Il primo passo è sempre quello di creare in TF Service il progetto di destinazione con lo stesso Process Template ed inserire tutti gli utenti con i LiveId.

L’account che userete per connettervi al Team Project di partenza deve far parte del Project Collection Service Account, questo perché ha bisogno di privilegi speciali per fare la migrazione. Se state quindi usando un vostro utente ricordatevi di associarlo al gruppo Project Collection Service Account. A questo punto aprite il programma Tfs Integration Tools, scegliete una one-way migration e scegliete tra i template disponibili il VersionControlAndWorkItemTracking per migrare Work Item e sorgenti.

La configurazione minima è veramente banale, è infatti sufficiente andare ad impostare sorgente e destinazione sia per il Source Control, sia per i Work item, cliccando sui vari tasti configure presenti nell’interfaccia, e scegliendo il TFS11 Migration VC Provider

Nell’immagine potete vedere che ho scelto come sorgente il progetto FabrikamFiber presente sulla macchina virtuale di test di Brian Keller, come destinazione sceglierete quindi il progetto che avete creato su Team Foundation Service. A questo punto potete scegliere per il Source Control i percorsi che volete migrare, come mostrato in figura

Questa operazione, oltre a permettere il trasferimento di una porzione di source control vi evita di dovere gestire il conflitto che si crea nei file di definizione della build, presenti sia sul progetto sorgente e destinazione, per intenderci quelli che sono dentro la cartella BuildProcessTemplate. Mappando tutte le cartelle della root si evita il problema.

Una volta che avete preparato tutto basta salvare la configurazione nel database e premere Start per iniziare il trasferimento. Naturalmente è possibile anche configurare separatamente il trasferimento del source contorl e dei Work Item, opzione utile se ad esempio volete migrare solamente i sorgenti o solamente i work item. In entrambi i casi l’integration platform vi mostrera una finestra con i progressi dell’operazione, dove verrete anche informati di eventuali conflitti o problemi a runtime.

Se il team project di destinazione è vuoto, l’unico conflitto che potete avere è quello sui file di definizione della build, che viene evitato semplicemente mappando le singole cartelle come mostrato in precedenza. Al termine della migrazione potete verificare che tutto funzioni correttamente andando a visualizzare il contenuto del progetto di destinazione.

In questo caso possiamo vedere che nel source control la history è preservata correttamente e cosa molto importante, sono preservati anche gli utenti, nonostante non siano presenti nel progetto di destinazione. L’unica reale differenza è che le date di check-in sono quelle di quando è stata effettuata la migrazione, ma nei commenti trovate la data originale corretta, per cui l’informazione non è comunque persa.

Un’altra differenza risiede nel fatto che le cartelle Main, Dev e Releases non sono convertite in Branch, come nel progetto sorgente, ma come potete vedere dalla figura sono normali cartelle (non hanno l’icona delle branch). Anche questo non è un problema, perché in realtà le relazioni di branch sono correttamente preservate (come potete vedere visualizzando le proprietà della cartella main), per cui è sufficiente fare un convert to branch sulla cartella principale da cui avete branchato (in questo caso la Main) e Visual Studio convertirà in branch a cascata tutte le altre cartelle.

Come potete vedere dalla figura, il convert to branch correttamente ripristina la visualizzazione delle branch introdotta con TFS2010.

Anche per i Work Item, se la migrazione è andata a buon fine vi troverete tutte le informazioni migrate, compresa la history.

Come si può vedere è stata mantenuta la gerarchia dei work item, l’utente a cui è stato assegnato il work item ed anche la history.

Naturalmente dovrete poi impostare manualmente nel Team Project di destinazione: aree, iterazioni, date di iterazione etc etc, perché tutte queste informazioni non sono migrate dall’integration Platform, cosi come le Build che debbono essere riconfigurate. Nel caso dei Work Item il fatto che gli utenti mantengano il loro nome originale, che non è presente nel Team Project di destinazione influisce sulla pianificazione agile dello sprint corrente, per cui se state sviluppando Scrum, potrebbe essere una buona cosa mappare gli utenti nel file di configurazione nella Integration Platform, oppure effettuare la migrazione al termine di uno sprint, cosi da potere iniziare con gli utenti reali nello sprint successivo.

Mappare gli utenti

Per quanto riguarda i Work Item, il fatto che gli utenti siano rimasti quelli del sistema sorgente è un fattore alquanto fastidioso, quando un utente farà login in TF Service e cercherà ad esempio i bug o i task assegnati a lui, non troverà infatti nulla, dato che tutti i Work Item punteranno al suo vecchio utente, valido solamente nel sistema on-premise.

Per evitare questo problema è sufficiente andare a configurare un mapping statico degli utenti premendo il bottone Edit XML e configurando la migrazione dei Work Item come nell’esempio sottostante

<SettingXml>

  <WITSessionCustomSetting>

    <Settings />

    <WorkItemTypes>

      <WorkItemType LeftWorkItemTypeName="*" RightWorkItemTypeName="*" fieldMap="FieldMap" />

    </WorkItemTypes>

    <FieldMaps>

      <FieldMap name="FieldMap">

        <MappedFields>

          <MappedField LeftName="*" RightName="*" MapFromSide="Left" valueMap="" />

          <MappedField LeftName="System.AssignedTo" RightName="System.AssignedTo" MapFromSide="Left" valueMap="UserMap" />

        </MappedFields>

      </FieldMap>

    </FieldMaps>

    <ValueMaps>

      <ValueMap name="UserMap">

        <Value LeftValue="Brian Keller" RightValue="alkampfer@outlook.com" />

        <Value LeftValue="Julia Iliyiana" RightValue="alkampfer@nablasoft.com" />

      </ValueMap>

    </ValueMaps>

  </WITSessionCustomSetting>

</SettingXml>

<SettingXmlSchema />

La configurazione è molto semplice, si indica semplicemente di mappare tutti i work item utilizzando una mappa chiamata FieldMap che permette di specificare come i vari campi saranno mappati tra il progetto sorgente e destinazione. Questa configurazione è fondamentale ad esempio se state migrando tra differenti template, perché i vari campi dei Work Item non corrisponderanno, in questo caso invece viene usata per mappare gli utenti.

Di base la nostra FieldMap mappa tutti i campi indicando asterisco, ma per il campo System.AssignedTo viene specificata una valueMap differente chiamata UserMap. Una valueMap non fa altro che trasformare il valore di un campo durante il trasferimento, esistono dei plugin che permettono di effettuare mappature automatiche, ma in questo caso l’unica opzione da usare è semplicemente inserire un mapping statico che vada a cambiare il nome utente. Per verificare che le opzioni siano state inserite correttamente dovreste vedere l’interfaccia utente modificata in questo modo.

A questo punto quando effettuerete le migrazioni gli utenti verranno convertiti mantenendo quindi l’assegnazione corretta dei Work Item.

Naturalmente è possibile utilizzare la stessa tecnica anche per migrare un progetto da una versione di TFS antecedente la 2012 ad un TF Service o anche per migrare da TF Service ad un TFS locale.