DevOps

Retour d'expérience - Migration TFS vers Azure DevOps

Lionel Gurret
6 min de lecture
#Azure #CICD
Retour d'expérience - Migration TFS vers Azure DevOps

Introduction

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 :

  • Mises à jour automatiques de la part de Microsoft
  • Économies de temps et d’argent au niveau opérationnel
  • Certifications de conformité (ISO 27001, SOC 1, SOC 2 et HIPAA BAA)
  • Accès à Azure DevOps depuis n’importe où et sur tous les appareils
  • 99,9% de disponibilité garantie
  • Support

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.

Déroulement de l ‘intervention

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.

  • Télécharger le TFS Migrator : Lien et extraire les données
  • Lancer la commande système suivante sur votre / vos collection(s) :
    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.

  • Lancer la commande système suivante sur votre / vos collection(s) :
    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 :

  • Détacher vos collections d’Azure DevOps Server
  • Pour chacune de vos collections, générer le(s) fichier(s) DACPAC via les lignes de commande suivante :
cd "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130" 

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=Memory

Vos 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:\migration\Logs\Collection-Name\Date\.

Ouvrir ce dernier et le compléter en vue de la migration dry-run :

Remplacer les champs suivants :

  • Location : Fournir la SASKey de votre Azure storage container
  • Dacpac : Entrer le chemin de votre fichier DACPAC uploadé
  • Target Name : Le nom de l’organisation Azure DevOps a créer (utiliser un nom temporaire pour un dry-run)
  • ImportType : Mettre DryRun pour faire un test de migration ou Production pour une migration définitive.
    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:\migration\Logs\Collection\XXXXX\import.json

Un 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.

Retour d’expérience et difficultés rencontrées

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.

  • Assurez vous de configurer correctement votre AAD (Azure Active Directory.) Cette étape vous permettra d’avoir vos groupes et vos utilisateurs configurés directement après la migration.
  • Penser à réserver dès que possible votre nom d’organisation (ex : my-great-place-to-work) dans Azure DevOps. Il est possible le renommer une organisation à tout moment. Vous pouvez donc faire vos tests (dry-run) sur des organisations temporaires (ex: my-great-place-to-work-test1).
  • Le nettoyage des bases de données peut s’avérer capricieux. En effet, certains jobs automatiques de nettoyage ne fonctionnaient pas sur le serveur à migrer. Il est donc intéressant de s’occuper du nettoyage des bases dans une première intervention planifiée en s’appuyant sur un snapshot VM.
  • Lister en amont avec vos équipes les différents points et pipelines à tester en priorité après la migration.
  • Récupérer via l’API Azure DevOps les pipelines et releases definitions de votre première migration dry-run faisant appel à des agents self hosted. En effet, les agents self-hosted n’étant pas migrés par Azure DevOps, vos pipelines n’auront pas d’agent de configurés.

Sources

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

Pour aller plus loin, découvrez notre formation Azure DevOps AZ-400 et notre consulting DevOps.