Migrazioni con la Team Foundation Server Integration Platform
di Matteo Emili - Microsoft MVP
.png "JJ191716.7B654F178A3842F7F616A829DC6DF588(it-it,MSDN.10).png")
Giugno, 2012
Fino ad oggi integrare Team Foundation Server con altri strumenti di ALM (spaziando da CVS fino ad altri TFS) era estremamente complesso, necessitava di codice custom e, in definitiva, era un gran dispendio di tempo ed energie che difficilmente sarebbe stato poi riutilizzabile in altri scenari.
Sollevato il problema, quelli che erano ieri i Visual Studio Team System Rangers (oggi Visual Studio ALM Rangers, un gruppo di persone selezionate dalle community, dai Microsoft Consulting Services, e dai team di sviluppo) hanno avviato lo sviluppo di una soluzione.
E questa soluzione si chiama Team Foundation Server Integration Platform.
Si tratta di uno strumento molto potente, ed inoltre è un progetto opensource (ospitato all’indirizzo http://tfsintegration.codeplex.com). Essendo l’unico strumento di migrazione supportato da Microsoft, l’ultima versione con supporto è disponibile in Visual Studio Gallery (https://visualstudiogallery.msdn.microsoft.com/eb77e739-c98c-4e36-9ead-fa115b27fefe), mentre su CodePlex si trovano sia i sorgenti che tutte le beta e la documentazione.
Vediamo cosa troviamo, una volta installato:
- I tools
- Il TFS Migration Service
- L’SDK
- Una serie di adapter già pronti (altri sono scaricabili, ed il modello a plugin permette di scriverne in tempi relativamente brevi)
- Tantissima documentazione
Nella versione attuale (Marzo 2012, stabile) il tool principale (dal quale si effettua il 99% della configurazione e dell’esecuzione) è già comprensivo della GUI! Per chi ha lavorato con le precedenti Alpha e Beta, sapeva che non esisteva nulla di tutto ciò, e si utilizzava esclusivamente a linea di comando.
.png "JJ191716.ABB76000AFAB7E019FD759A83CD8F64A(it-it,MSDN.10).png")
Architettura
.png "JJ191716.C91F4EB84CC93A871A0BFB53D2CCF125(it-it,MSDN.10).png")
Gli attori sono tre: l’Adapter, il Synchronization Orchestrator e la Pipeline.
Il primo è un oggetto che permette di interpretare la sorgente o la destinazione, ed è quello che permette il dialogo fra la Pipeline ed il server.
La Pipeline è il cuore di tutto, e contiene il Synchronization Orchestrator.
Il Synchronization Orchestrator è l’oggetto che coordina i tre motori interni alla Pipeline.
C’è anche una comparsa, nell’ombra: un database.
Ora, cosa succede quando andiamo a fare una migrazione (per ora non ci addentriamo nelle configurazioni, rimaniamo nel teorico)?
Premettendo che tutto gira sotto la direzione del Synchronization Orchestrator, la prima cosa che accade è la generazione dei delta (relazioni comprese) della sorgente e della destinazione da parte dell’Analysis Engine. In caso di conflitti, il Conflict Resolution Engine li solleva e risolve automaticamente ove possibile (nel caso in cui non sia possibile, interviene l’utente). Una volta risolti, vengono salvati nel database tutti i dati e trasferiti dal Migration Engine.
Configurazioni
Le configurazioni possibili sono molteplici:
- One-way migration, ossia la cosiddetta “snapshot migration” (migrazione totale ad un preciso istante temporale)
- Two-way sync (sincronizzazione bidirezionale che avviene magari per allineare un TFS appena installato a quello già esistente, ad esempio)
- Custom
Ed è con la configurazione Custom che si aprono gli scenari più ampi in materia di integrazione. Perchè è possibile specificare oltre alla direzione (unidirezionale o bidirezionale) la frequenza.
La frequenza può essere:
- One Time
- Continuous Manual
- Continuous Automatic
Quest’ultima ci fa capire che può essere utilizzata anche come servizio di sincronizzazione continua (con l’ausilio del TFS Migration Service).
Adapter e Provider
Come abbiamo visto esiste un adapter per far comunicare la pipeline della Integration Plaform con i nostri strumenti. All’interno di un adapter è possibile ospitare dei provider, ognuno con un ruolo ben preciso.
Di default per Team Foundation Server ne abbiamo due, uno che si occupa del Version Control e l’altro dei Work Item. Ovviamente è possibile utilizzarne uno solo o più insieme, non siamo limitati, e soprattutto è possibile scriverne altri, mediante l’SDK.
Attualmente esistono provider per Team Foundation Server, IBM ClearCase e ClearQuest, Subversion e il File System.
Scenario
Utilizziamo uno scenario abbastanza semplice, per comodità: snapshot migration di Version Control e Work Items fra due Team Foundation Server 2012.
In un TFS ho una Project Collection (DefaultCollection) contenente un Team Project chiamato “Demo Agile” con del codice ed alcuni Work Item, legati fra di loro con una relazione padre-figlio.
Nell’istanza “vuota” invece ho la Project Collection di default contenente un Team Project chiamato “Migration”, completamente vuoto.
.png "JJ191716.97ACA581B2A004111DBE6549C95C64B4(it-it,MSDN.10).png")
.png "JJ191716.1AEA9C11D5FA2FDAC55CF34E68E4F96F(it-it,MSDN.10).png")
.png "JJ191716.B46466B70732422B28330C9293CC191B(it-it,MSDN.10).png")
Demo
Apriamo la console, e creiamo una nuova configurazione per la migrazione.
.png "JJ191716.B51C2FA3CA1F8FD39AF8DEDA7AB357A6(it-it,MSDN.10).png")
Devo scegliere un template. Ne ho a disposizione diversi, che spaziano dall’integrazione fra TFS fino a connettori per IBM Rational ClearCase e ClearQuest, o anche al file system.
.png "JJ191716.8E9A007DE66A40E87765A0D27B0E4F1D(it-it,MSDN.10).png")
Nel nostro caso, fra quelli per Team Foundation Server, scelgo quello che mi permette di fare migrazione di VC e WIT.
.png "JJ191716.A54D8BDB26445B499B969738C1F5F0BC(it-it,MSDN.10).png")
Fatto questo, assegno un nome alla configurazione e lascio invariato il tipo di workflow (one-way migration, in questo caso). Configuro le sorgenti e le destinazioni mediante la stessa user interface che utilizzo nel Team Explorer per selezionare il Team Project a cui mi debbo collegare.
Una piccola nota: per “Left Source” si intende sempre la partenza, quindi bisogna inserire il Team Foundation Server contenente i dati da sincronizzare.
E’ possibile aggiungere alcuni settaggi personalizzati (cosa che per ora non faremo), ma soprattutto qualunque impostazione è completamente modificabile sia da UI, che da visualizzazione XML.
.png "JJ191716.CFF8160781C68FA544F139BE5685E4D7(it-it,MSDN.10).png")
.png "JJ191716.21295E333FB8C2BD4356D0F0C5FC512D(it-it,MSDN.10).png")
Tutto quello che è visualizzato proviene da un file di configurazione.
.png "JJ191716.C3DACB7D42A153DDAC39266F71906F29(it-it,MSDN.10).png")
Fatto ciò salviamo nel database la configurazione, e siamo pronti a far partire la migrazione.
.png "JJ191716.A6F40F0F23A10558178EA76173379726(it-it,MSDN.10).png")
Verranno sollevati alcuni conflitti che il Conflict Resolution Engine non è riuscito a risolvere. Ecco come si presentano:
.png "JJ191716.A6B52BA27B244FF75800B8B783C378F4(it-it,MSDN.10).png")
.png "JJ191716.0C4CAF9FA629DC81118ABF2D481B60AE(it-it,MSDN.10).png")
A volte, basterà un retry dell’operazione senza alcuna modifica, altrimenti potrebbe essere necessario scegliere uno dei due file, oppure eseguire un merge dei due changeset (che potrà essere ancora una volta automatico o manuale, come ben sappiamo). In questo caso, la versione da tenere in considerazione è quella della sorgente, quindi risolviamo rapidamente indicando il changeset di riferimento.
Esiste inoltre un Rules Manager, per impostare delle regole da far eseguire automaticamente.
Alla fine, otteniamo un confortante feedback:
.png "JJ191716.6475E454361ADC3B53548EE0151C1A58(it-it,MSDN.10).png")
Oltre a delle statistiche sulla migrazione ed i conflitti:
.png "JJ191716.739F5B31D7112C693142B6EC2F1734CA(it-it,MSDN.10).png")
Migrazione terminata.
Limiti
Gli oggetti che vengono migrati sono, evidentemente, solo i Work Item ed il codice sorgente (con i relativi collegamenti fra di loro).
Non vengono preservati gli ID dei Work Item ed i changeset numbers, ma sono riassegnati sequenzialmente durante la migrazione (mantenendo comunque validi tutti i link), cosi come i timestamps delle revisioni sono tutti azzerati al momento della migrazione.
.png "JJ191716.91D39A44647D350E2B58070202FCA1FD(it-it,MSDN.10).png")