Récemment, nous avons eu la chance de pouvoir accompagner l’un de nos partenaires de longue date au cours d’une migration depuis leur serveur TFS 2013 vers Visual Studio Team Services.

Depuis Microsoft Connect qui a eu lieu le 16 novembre 2016,  Microsoft a mis à notre disposition une procédure de migration depuis TFS vers VSTS en Public Preview. Elle consiste en une procédure de 58 pages en anglais décrivant étapes par étapes, les différentes actions à effectuer pour réussir cette migration ( https://aka.ms/TFSImportData ); ainsi que d’un outil utilisable en ligne de commande appelé TfsMigrator qui va nous permettre de valider et préparer notre migration.

Le processus est découpé en 27 étapes, elles-mêmes regroupées en 6 grandes étapes :

1. Démarrage
2. Prérequis
3. Mise à jour
4. Validation
5. Préparation
6. Import

Plutôt que de décrire une par une chacune de ces étapes (ce qui prendrait bien plus qu’un simple article de blog), voyons ensemble les principaux points clés identifiés

Démarrage et Prérequis

En termes de prérequis spécifiques à la migration vers VSTS, on en retiendra principalement trois :

1. Avoir un Azure AD (Active Directory) synchronisé à votre AD local
2. Réserver le plus tôt possible le nom de domaine .visualstudio.com
3. Remplir le questionnaire à destination de Microsoft
   • Vérifier que la collation SQL fait bien partie de celles qui sont supportées (SQL_Latin1_General_CP1_CI_AS ou Latin1_General_CI_AS)

La synchronisation Azure AD et AD Local peut se faire assez facilement via Azure AD Connect, et est peut-être déjà effective dans votre entreprise si vous avez connecté votre AD Local à Office 365.

La réservation du nom de domaine en .visualstudio.com vous permettra simplement de vous assurer dès maintenant que le nom de domaine sous le format MON_NOM_DENTREPRISE.visualstudio.com soit bien disponible une fois la migration terminée. En effet la migration vers VSTS produira un compte au format MA_MIGRATION_DE_TEST-prod.visualstudio.com, qu’il suffira de renommer suivant le nom de domaine pré-réservé durant cette étape.

Enfin le questionnaire (en anglais) est accessible au lien ci-dessous : https://aka.ms/vstsdataimportpreviewform

Celui-ci permet d’obtenir deux codes de migration pour effectuer une migration de test ainsi qu’une migration de production.

Durant le remplissage du questionnaire, la collation SQL est demandée car à l’heure actuelle, seules 2 collations sont complètement supportées dans l’outil de migration (SQL_Latin1_General_CP1_CI_AS ou Latin1_General_CI_AS). Mais il est bon de noter qu’il est possible d’effectuer la migration dans une autre collation (SQL_Latin1_General_CPI1_CI_AS_WS_KS dans notre cas), avec un léger risque potentiel lié à l’encodage du contenu de TFS (notamment le contenu des Work Items)

Mise à jour

La migration vers VSTS ne sera possible que dans les versions les plus récentes de TFS, à l’Update près (À l’heure actuelle TFS 2017 RTM + TFS 2015 Update 3 jusqu’en Mars 2017).

Globalement Microsoft prévoit néanmoins de supporter la Migration vers VSTS de ses versions de TFS durant les 6 mois suivant la mise à disposition publique, comme l’illustre le schéma suivant :

Suivant la version de TFS déjà mise en place chez vous, un chemin de migration est proposé par Microsoft, comprenant une ou plusieurs étapes intermédiaires si la version de TFS est trop ancienne

Validation et Préparation

Pour cette phase de validation/préparation, c’est l’outil TfsMigrator.exe qui va entrer en jeu.

Ce dernier dispose de trois modes de fonctionnement, matérialisés sous la forme de paramètres : Validate, Prepare et Import.

Le mode de fonctionnement de validation (Validate) va permettre d’analyser le contenu de votre collection de projet TFS (en se connectant sur sa base de données). L’exécution de cette ligne de commande va produire des logs, notamment le fichier TfsMigrator.log qui devra être analysé afin de préparer les actions à effectuer sur le serveur TFS avant de pouvoir migrer vers VSTS

 Les différentes erreurs remontées par l’outil de validation sont généralement documentées sur le MSDN https://aka.ms/VSTSProcessErrors

Dans notre cas, nous avons juste rencontré 2 erreurs :

• Il n’est pas possible d’avoir un champ custom possédant le même label qu’un des champs par défaut de VSTS : Problème corrigé très simplement en suffixant le champ custom par le nom de l’entreprise par exemple
• Il manquait des permissions sur certains groupes de sécurité au niveau de la collection de projet d’équipe : Les sécurités ont été ajoutées via l’outil en ligne de commande TFSSecurity.exe

Une fois la validation réussie, il convient ensuite de passer à l’étape de préparation (Prepare). Il faut alors préciser un compte Azure AD qui sera utilisé pour générer le fichier de mapping (liaisons) IdentityMap.csv entre les comptes d’utilisateurs locaux et leurs comptes sur Azure AD.

À noter que le fichier IdentityMap.csv contient également la licence (StakeHolder, Basic ou MSDN) qui sera automatiquement affectée aux utilisateurs migrés sur VSTS.

Un autre fichier est généré suite à l’exécution du mode Prepare : le fichier import.json qui contient la configuration utilisée durant l’import.

Les différents paramètres à renseigner sont :

• "Source:Location" : La clé SAS d'un conteneur de stockage Azure (à créer si nécessaire) dans lequel il est nécessaire d'uploader le fichier IdentityMap.csv, ainsi que le fichier .dacpac généré durant la dernière étape de migration
• "Target:AccountName" : Le nom du compte VSTS qui sera créé durant l'import. Par exemple pour une valeur égale à "monentreprise", un compte VSTS sera créé avec comme URL http://monentreprise-dryrun.visualstudio.com pour la migration de test
• "Target:Properties:Region" : Vraisemblablement WEU (pour West Europe) pour les lecteurs Français de ce blog et CUS (Central US) pour les lecteurs Canadiens 😊
• "Properties:ImportCode" : Le code fourni par Microsoft après envoi du formulaire décrit dans l'étape Démarrage et Prérequis

Import

Dernière étape avant d'avoir un environnement de test fonctionnel (ou une migration réussie) : L'étape d'import.

La première étape consiste à créer un .dacpac de la base de données de collection de projets d'équipes de TFS. C'est une étape assez longue (dans notre cas pour une base de données de 360GO, l'opération a duré plus de 10 heures), pour laquelle il ne faut pas oublier de détacher la collection de projets d'équipe de TFS à priori.

Seconde étape également très longue : elle consiste à uploader le .dacpac ainsi généré dans le conteneur de stockage Azure dont la clé SAS a été précisée dans le fichier de configuration import.json. Là encore suivant la taille du .dacpac généré ainsi que de la bande passante en upload de votre connexion internet, cette étape peut facilement prendre plusieurs heures.

Une fois tous les préparatifs terminés, il ne reste plus qu'à exécuter l'outil TfsMigrator suivi de l'argument import, ainsi que du fichier de config import.json pour démarrer le processus d'import de votre base de données sur VSTS.

Au bout de quelques heures, Microsoft envoie un email pour signaler du bon déroulement de la migration (de test ou de production)

Conclusion

Les raisons pour migrer sur la version Cloud de TFS sont multiples (Plus d'une dizaine de nouvelles fonctionnalités toutes les 3 semaines, accessibles depuis n'importe où, affranchissement de la maintenance de l'infrastructure du produit, sécurité accrue grâce au stockage des données dans les Datacenter hautement sécurisés de Microsoft, etc.), et jusqu'à présent il était difficile de migrer vers VSTS sans perdre tout ou partie de son historique (de Code Source, de Work Items ou autre).

Dorénavant avec ce nouveau processus de migration, les personnes voulant bénéficier de la puissance du Cloud sans perdre l'historique de leur TFS local sont maintenant dotées d'un outil de choix.