By Lionel Gurret.
Les équipes de Sokube ont récemment eu l’occasion de migrer une infrastructure on-premise TFS Server vers l’offre cloud Azure DevOps Services.
Les raisons qui pourraient vous pousser à réaliser cette opération sont multiples :
Dans cet article, nous détaillerons les différentes étapes nécessaires au processus de migration puis nous partagerons notre retour d’expérience et les difficultés rencontrées.
Le workflow suivant illustre les différentes étapes du processus de migration que nous allons analyser :
0 – Mise à jour d’Azure DevOps Server (TFS)
Avant de pouvoir lancer la migration, il est nécessaire d’avoir une version de Windows récente (Windows 2019) ainsi qu’une version récente d’Azure DevOps Server (2020).
Aucune difficulté rencontrée. Il est important de prévoir suffisamment de ressources hardware (disque, CPU, RAM) pour l’opération.1- Modification du Firewall
La première étape de notre migration consiste à couper le firewall (port 80 et 443) sur la production (firewall local et / ou externe) afin d’éviter les modifications sur les différentes collections TFS.
2 – Nettoyage des bases de données des collections
Cette étape est la plus importante. En effet, réduire considérablement la taille de vos collections, vous permettra de migrer plus facilement et plus rapidement vers Azure DevOps Services.
Je vous conseille de lire l’article suivant de Marcus Felling pour compléter les commandes fournies dans cet article et optimiser l’espace de vos collections : How to reduce the size of your TFS/Azure DevOps Server collection databases
La taille des données ne doit pas dépasser 30GB par collection. Si ce n’est pas le cas, il est conseillé de passer par un serveur Azure intermédiaire pour effectuer la migration. En utilisant ces requêtes nous avons pu faire baisser la taille de collections de 110GB à 20GB !3 – Validation des données à migrer
Nous pouvons à présent entrer dans le coeur du sujet ! La première étape en vue de lancer un import dans Azure DevOps est de valider nos données présentes sur Azure DevOps Server 2020.
Migrator validate /collection:{Collection URL} /tenantDomainName:{Name}
Lorsque le migrator vous le demande, configurez bien le fuseau horaire qui correspond à la timezone de votre Tenant Azure. (ex: WEU) Afin de pouvoir continuer le processus de migration, veuillez résoudre tous les points en erreurs remontés par le migrator. Voici une [documentation ](https://aka.ms/AzureDevOpsImportTroubleshooting)utile pour les différentes erreurs connues. De notre côté, nous n’avons eu qu’un warning lié une “database collation” qui a pu être ignoré.4 – Préparation de la migration
Cette étape est proche de la précédente. Ici nous allons générer les fichiers import.json et IdentityMapLog.csv, utilisés par l’outil de migration.
Migrator prepare /collection:{Collection URL} /tenantDomainName:{Name}
Répondre aux différentes questions de l’assistant, puis valider le fichier IdentityMapLog. Corriger sur Azure Active Directory le ou les comptes qui n’auraient pas été synchronisés. Nous n’avons pas eu de problème, tous les comptes étaient bien synchronisés !5 – Génération d’un fichier DACPAC
Pour pouvoir transférer les données présentes dans nos bases, il est nécessaire de générer un fichier DACPAC depuis les bases SQL Server. Ce fichier contient une collection de fichiers XMLs qui définissent le schéma et les données à transférer. Il sera utilisé par Azure DevOps Services pour la migration.
Pour cela :
cd "C:Program Files (x86)Microsoft Visual Studio2019CommunityCommon7IDEExtensionsMicrosoftSQLDBDAC130"
SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog={COLLECTION DB NAME};Integrated Security=True" /targetFile:{DACPAC FILE PATH} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=MemoryVos fichiers DACPAC doivent ensuite être copiés sur le blob container Azure storage.
Cette opération peut être faite manuellement via l’Azure Containr Explorer ou plus rapidement en utilisant AZCopy :
azcopy make 'https://<storage-account-name>.file.core.windows.net/<file-share-name><SAS-token>'6 – Modification du fichier import.json
Après avoir lancé la préparation des données, un fichier import.json a été généré dans le dossier C:migrationLogsCollection-NameDate.
Ouvrir ce dernier et le compléter en vue de la migration dry-run :
Remplacer les champs suivants :
Avec une migration dry-run, vous vous assurez que les données migrées seront automatiquement supprimées entre 15 et 21 jours après migration.7 – Lancement de la migration
Lancer à présent les commandes suivantes pour chacune de vos collections:
Migrator import /importFile:C:migrationLogsCollectionXXXXXimport.jsonUn lien vous est donné pour suivre l’avancement de l’import :
Une fois la migration commencée et terminée, un email vous sera envoyé.
Nous avons constaté des temps très différents pour les mêmes interventions et les mêmes données transférées (de 3 à 10 heures.) Ces variations de temps sont en grande partie expliqués par le fait qu’Azure lance la migration au moment jugé opportun. Vous pouvez à présent valider les données migrées avec vos utilisateurs avant de passer à l’intervention définitive.Une fois les bases de données réduites, le processus de migration d’Azure DevOps est très fiable.
Néanmoins, plusieurs points sont à prendre en compte afin de se mettre dans les meilleures disponibilités.
How to reduce the size of your TFS/Azure DevOps Server collection databases
Migrating from TFS to the Cloud… Without Losing Your Mind
Azure DevOps Server to Services Migration overview – Azure DevOps