Questo post è stato scritto da Davide Benvegnù di DotNetToscana.
Il passato
In passato, quando ancora la versione "on-cloud" di Team Foundation Server (TFS) si chiamava "Team Foundation Services" e non era ancora stata rilasciata in GA, la migrazione da un nostro TFS on-premises alla versione online era, seppur possibile, abbastanza complessa.
L'opzione più rapida, ma che di fatto non era una vera e propria migrazione, era sostanzialmente quella di creare un Team Project nuovo su Team Foundation Services, mapparlo sul workspace, copiare la versione più recente dei sorgenti e fare check-in. Un approccio simile poteva essere usato per i Work Item, bastava infatti creare una query che recupera tutti i work item di quello specifico team project ed aprirla in Excel 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; un "publish" salverà tutti i dati.
In questo modo avevamo tutti gli elementi di lavoro ed i sorgenti sul sistema online, ma perdendo tutta l'history e, per quanto riguarda i workitem, tutti gli oggetti "avanzati" (campi html, allegati, commenti...)
Un'altra opzione, la migliore disponibile allora, era 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. Sebbene il tool sia molto potente e sicuramente ben realizzato, la migrazione avveniva non senza intoppi e richiedeva comunque una buona dose di interventi manuali (ad esempio la mappatura degli utenti, che richiedeva la modifica di un file xml).
La situazione attuale
Con il rilascio in GA di Visual Studio Online (VSO) e, soprattutto, con l'annuncio della disponibilità delle sue Open API basate su REST, la situazione è notevolmente migliorata. Queste API, infatti, affiancandosi ai normali endpoint di cui sia TFS che VSO sono forniti, permettono un controllo molto più profondo e puntuale sulle singole parti del sistema, sia per quanto riguarda la funzionalità di Source Control sia per la gestione dei WorkItem. È quindi ora possibile realizzare delle soluzioni software che, utilizzando proprio queste API, possono interagire con il sistema e migrare tutti i nostri dati dal nostro TFS on-premises a VSO.
Un'ulteriore buona notizia è che è stata anche rilasciata un'utility completamente gratuita, realizzata dall'azienda OpsHub in stretta collaborazione con il team di Microsoft che si occupa dello sviluppo di TFS e VSO, che ci permette di effettuare la migrazione in pochi passaggi e con pochi clic. Questa utility (il cui nome è OpsHub Visual Studio Online Migration Utility) è inoltre mantenuta costantemente aggiornata.
Perché dovrei passare da TFS a VSO?
Prima di vedere in pratica il "come" fare, analizziamo un attimo il "perché".
Ci sono molti motivi che ci potrebbero spingere a migrare dal TFS che abbiamo in casa ad una soluzione on-cloud. Quelli più frequenti sono:
· Aggiornamento da TFS vecchio (< 2013)
o Se dispongo di un TFS precedente al 2013 e voglio passare all'ultima versione, non è detto che le cose siano semplicissime. Oltre a dovermi preoccupare dell'installazione dell'update, ci sono anche altri elementi che vanno presi in considerazione. Ad esempio una nuova versione di TFS ha dei requisiti HW/SW maggiori rispetto alle versioni precedenti, quindi per poter aggiornare devo verificare che tutti i nuovi requisiti siano soddisfatti e andare ad acquistare nuovo hardware o nuove licenze software dove non lo siano.
o Passando a VSO non mi devo preoccupare di aggiornamenti HW e SW
· Ho già TFS 2013 ma devo scalare
o Supponiamo di avere una nostra infrastruttura interna basata su TFS, dimensionata per gestire al massimo 100 utenti. Cosa succede se il team di lavoro cresce e ci ritroviamo ad avere un team di 300 persone? Oppure se nell'installazione fatta avevamo utilizzato SQL Server Express ma ci accorgiamo che abbiamo bisogno di un'altra versione di SQL Server?
o Se passo a VSO non mi devo preoccupare né dell'Hardware né delle versioni Software in quanto fornito in SaaS
· Sto migrando tutto sul cloud
o Sempre più aziende, soprattutto di piccole e medie dimensioni, stanno abbandonando i DataCenter on-premises per affidarsi totalmente a soluzioni nel Cloud.
o Passando a Visual Studio Online è possibile andare a dismettere anche i server che stiamo utilizzando per gestire la nostra piattaforma di ALM
· Voglio poter avere sempre l'ultima versione disponibile di TFS, senza dovermi preoccupare degli aggiornamenti, delle configurazioni di sistema, dell'installazione…
o Visual Studio Online offre proprio questo (e molto di più).
Per avere una panoramica delle differenze tra la versione di Team Foundation Server disponibile e Visual Studio Online, potete consultare questo link: http://www.visualstudio.com/en-us/news/release-archive-vso
Come funziona l’utility di migrazione
Vediamo come funziona l'utility di migrazione:
· Supporta una migrazione one way (solo da TFS a VSO)
· Supporta la migrazione da TFS 2010, TFS 2012 e TFS 2013
· Utilizza i "normali" endpoint per connettersi a TFS ed esportare i dati
· Utilizza sia gli endpoint classici che le nuove Open API (REST Based) per importare i dati in VSO
· La migrazione avviene a livello di Team Project (non è quindi possibile migrare eventuali dati associati alla Team Project Collection)
L'ultima versione del tool ha introdotto anche la migrazione incrementale, ovvero è possibile ripetere la migrazione più volte andando di volta in volta ad importare su VSO solo gli elementi che precedentemente non erano stati migrati (cosa che non era possibile nelle versioni precedenti)
Il tool ha delle limitazioni su quanto viene migrato. Gli elementi di cui è supportata la migrazione sono:
· Codice sorgente sotto TFVC (inclusi changeset, label e history) – GIT non è supportato
· Aree e Iteration
· Work item, inclusi link, tag ed allegati (Esclusa ogni customizzazione e dati associati, come ad esempio campi custom, workflow custom, ecc)
· Immagini allegate ai work item
· Test suite, test case, test run e test result salvati
· Ogni “history action” per conto dell'utente originale in modo da preservare il più possibile la storia.
È importante notare che il tool non migra le customizzazoni, quindi se abbiamo delle esigenze in tal senso dovremmo orientarci verso altre soluzioni. Attenzione che se, durante la fase di verifica, l'utility rileva personalizzazioni ai Work Item Types restituisce un errore e non sarò possibile procedere alla migrazione.
Per ovviare a questo problema è necessario rimuovere le personalizzazioni; il modo più veloce per farlo è scaricare dal TFS i file xml del process template "standard" usato per creare il Team Project e riapplicarli sul progetto utilizzando il comando:
witadmin importwitd /collection:CollectionURL [/p:ProjectName] /f:FileName [/v]
Migriamo
Innanzitutto bisogna assicurarsi che l'account VSO che useremo per effettuare la migrazione sia membro del gruppo "Project Collection Service Accounts". Se non lo fosse, dobbiamo inserircelo dal portale della nostra sottoscrizione Visual Studio Online.
Dopo aver fatto login al portale, è sufficiente cliccare sul pulsantino delle impostazioni in alto a destra, selezionare il link "Manage collection security and group membership", andare sulla sezione "Users" e da lì impostare il gruppo all'utente.
Fatto questo, è necessario creare su Visual Studio Online un Team Project che abbia esattamente lo stesso nome del progetto che vogliamo migrare e che utilizzi lo stesso tipo di Process Template (ad esempio se ho creato il progetto sulmio TFS usanto il Process Template Scrum, dovrò utilizzare questo template anche per la creazione del progetto su VSO).
A questo punto è possibile iniziare la fase di migrazione vera e propria, lanciando l'utility.
Appena partita, selezioniamo la voce di menu "New Migration"
È necessario poi inserire gli endpoint sia per il TFS che abbiamo on–premises sia per Visual Studio Online. Per TFS è necessario anche specificare la Team Project Collection che contiene il/i progetto/i da migrare.
Per farlo è sufficiente inserire gli stessi dati che andremmo ad inserire in Visual Studio per connetterci:
Cliccando su “Next” è possibile dare un nome alla migrazione che andremo ad effettuare e, soprattutto, scegliere che cosa vogliamo migrare: solo i sorgenti, solo i work item oppure tutto.
Dopo aver nuovamente cliccato su “Next”, l’utility interroga il server TFS per proporre la lista dei progetti presenti nella Team Project Collection che abbiamo precedentemente selezionato e ci viene proposta una pagina in cui selezionare uno o più progetti da migrare.
È interessante notare che se selezioniamo un progetto che non è già stato creato anche su VSO l’utility ci avvisa e non ci permette di continuare nella migrazione.
Effettuata la selezione, dobbiamo preoccuparci della mappatura degli utenti. Il tool, infatti, non importa direttamente gli utenti che trova su TFS ma ha bisogno che gli venga indicata una mappatura tra gli utenti. È possibile anche mappare più utenti TFS ad un solo utente VSO, dipende dal livello di coerenza che si vuole mantenere. Nonostante gli utenti siano diversi, a fine migrazione per tutti gli elementi di lavoro sarà comunque disponibile un riferimento all’utente originale.
Per mappare uno o più utenti TFS ad un utente VSO è sufficiente cliccare sul nome dell’utente originale nella casella di sinistra e su quello di destinazione nella casella di destra e premere il pulsantino con la freccia. Fino a che non avremo mappato tutti gli utenti, non sarà possibile continuare.
Cliccando su “Next” parte la fase di validazione, in cui l’utility verifica che siano soddisfatti i requisiti per la migrazione (sostanzialmente, verifica che il Project Template usato sia dello stesso tipo su entrambi i progetti e che il progetto TFS non presenti customizzazioni)
Se la validazione termina in modo positivo, cliccando su “Finish” si fa partire la migrazione, che avviene in due fasi.
La prima fase è quella della configurazione, in cui vengono raccolti i dati relativi al progetto su TFS e vengono creati script e raccolte che verranno poi utilizzati dalla migrazione effettiva.
Se anche questa fase passa senza intoppi, viene proposto un box di conferma che, in caso di risposta positiva, dà il via al processo di migrazione effettivo.
Durante la migrazione, vengono indicati gli stati di progress ed eventuali warning (ovvero gli elementi indicati in “pending for retry”). Se abbiamo deciso di migrare sia i sorgenti che i workitem la schermata che avremo sarà come quella riportata di seguito, altrimenti vedremo solo uno dei due pannelli.
Se la migrazione ha dato esito positivo, tutti i campi riporteranno la scritta “Completed” in verde. In caso invece si fossero verificati dei problemi avremo l’indicazione di “Error” con un dettaglio del problema. A seconda dei casi potrebbe essere sufficiente sistemare il problema e riavviare la migrazione oppure potrebbe essere necessario, sempre dopo aver corretto l’errore, cancellare completamente il progetto da VSO e rifare da zero la migrazione.
Conclusioni
Grazie alle recenti feature release di VSO e a questa utility è molto semplice riuscire a migrare i nostri Team Project dal TFS che abbiamo in casa ad un account Visual Studio Online. Tuttavia, come visto, ci sono delle limitazioni che in alcuni casi potrebbero essere impattanti per noi o la nostra azienda.
Il consiglio è quello di fare sempre prima una migrazione di test (approfittando del fatto che VSO è gratuito fino a 5 utenti) e, conseguentemente, valutare se la soluzione proposta può andare bene per gli scenari in cui dobbiamo muoverci.
read full article
