Conseils pour la migration vers Azure DevOps Server

3 conseils pour réussir votre migration vers Azure DevOps Server

30 Décembre 2022

Azure DevOps Server 2022 est sorti le 06 décembre 2022.

Vos équipes utilisent une ancienne version de Azure DevOps Server voire une version de Team Foundation Server ? Vous envisagez sûrement une migration de votre version actuelle vers la dernière version de Azure DevOps Server ou bien de passer directement sur Azure DevOps Services.

Pour faciliter votre choix entre Azure DevOps Server et Azure DevOps Services, vous trouverez 6 éléments sur lesquels appuyer votre décision dans notre article Azure DevOps Services ou Server - 6 éléments pour choisir

Vous restez sur une version Server et souhaitez planifier une migration de votre système actuel vers Azure DevOps Server 2022 ?

Alors suivez les 3 conseils suivants :

  1. Eviter les migrations intermédiaires
  2. Exécuter une migration « test »
  3. Utiliser les sauvegardes planifiées de la console d’administration

Migrer rapidement pour éviter les migrations intermédiaires

Le premier conseil est de ne pas laisser s’accumuler les versions avant d’envisager une migration. Avoir deux ou trois versions d’écart maximum entre votre version et la dernière version de Azure DevOps est raisonnable.

On appelle migration intermédiaire une migration vers une version temporaire de Azure DevOps Server avant de rebondir vers une version supérieure jusqu’à arriver à la dernière version en date.

Figure 1 - Compatibilité des versions pour la mise à niveau vers Azure DevOps Server

Compatibilité des versions pour la mise à niveau vers Azure DevOps Server

Jusqu’à la version 2018 incluse, le produit s’appelait Team Foundation Server (TFS). A partir de la version 2019, il s’agit de Azure DevOps Server, à distinguer de la version Services de Azure DevOps qui est la version hébergée.

Pour comprendre l’historique des différentes versions : TFS/VSTS/Azure DevOps : comment s'y retrouver ?

D’après l’image ci-dessus, on constate que depuis une version TFS 2015 et supérieure, la migration sera directe vers Azure DevOps 2022.

En revanche, dans le pire des cas, une migration à partir d’une version TFS 2005 ou TFS 2008 exige trois migrations intermédiaires :

  1. De TFS 2005 ou TFS 2008 vers TFS 2010
  2. De TFS 2010 vers TFS 2013 Update 5
  3. De TFS 2013 Update 5 vers TFS 2015

Et encore une dernière pour enfin parvenir à Azure DevOps Server 2022 !

Alors quel est le problème posé par ces migrations intermédiaires ?

Techniquement parlant, il n’est pas plus compliqué de réaliser une migration directe qu’une migration avec étapes intermédiaires. Puisque le processus sera identique :

  • Sauvegarder les bases du serveur version n-1
  • Transférer ces bases vers le serveur version n
  • Restaurer les bases sur le serveur version n en migrant de la version n-1 à la version n

Réaliser deux ou trois fois ce processus au lieu d’une seule ne sera pas plus compliqué… mais beaucoup plus long !

Pour peu que vous ayez une volumétrie de données importante avec une taille des bases conséquente, les opérations de sauvegarde, de transfert et de restauration demanderont du temps. Et il faut songer au coefficient multiplicateur que représente le nombre de migrations intermédiaires.

La logistique sera également plus importante puisque chaque étape intermédiaire nécessitera un serveur, souvent une machine virtuelle, supplémentaire. Par exemple, si vous devez vous appuyer sur une migration intermédiaire TFS 2015, vous devrez provisionner temporairement un serveur hébergeant TFS 2015 en plus de votre serveur TFS actuel et du nouveau serveur Azure DevOps 2022.

Enfin, et c’est certainement là l’élément le plus important, le temps d’indisponibilité sera bien évidemment plus long en cas de migrations intermédiaires.

Pour une mise à niveau de TFS 2018 vers Azure DevOps Server 2022 et une volumétrie des données moyenne, la migration, et donc le temps d’indisponibilité du système, ne devrait pas excéder une demi-journée.

La même opération avec une ou deux migrations intermédiaires et une volumétrie des données importante peut conduire à une indisponibilité de plusieurs jours ouvrés. Pour les développeurs, surtout s’ils travaillent sur des projets Git, c’est envisageable. Mais pour les profils fonctionnels qui n’auront plus accès aux backlogs ni aux éléments de suivi de leurs projets, c’est plus gênant.

En résumé, selon votre version actuelle de TFS / Azure DevOps :

Versions TFS / Azure DevOps Urgence d’une migration
Azure DevOps 2019 ou 2020 Aucune urgence pour une mise à niveau sauf si vous souhaitez bénéficier des dernières fonctionnalités de Azure DevOps 2022
TFS 2017 ou 2018 Faites la mise à niveau vers Azure DevOps 2022 sans tarder, tant que vous pouvez encore la faire directement
TFS 2015 et inférieure Ne tardez pas non plus car plus vous attendrez, plus le nombre de migrations intermédiaires sera important

Conseil n°1 : pas plus de deux ou trois versions entre votre TFS / Azure DevOps et Azure DevOps Server 2022

Pas plus de trois versions entre TFS / Azure DevOps et Azure DevOps Server 2022

Exécuter une migration « test »

Le conseil n°1 ci-dessus a un effet direct sur la durée d’indisponibilité de votre système pendant une mise à niveau.

Comment connaître cette durée d’indisponibilité ?

La seule solution est d’exécuter une migration « test ». Pas forcément avec les dernières données à jour et, bien sûr, sans interrompre le service.

Cette migration « test » vous permettra de valider techniquement la migration et d’estimer le temps nécessaire à sa réalisation.

On a vu que la durée d’une mise à niveau dépendait essentiellement des manipulations des bases de données : sauvegarde, transfert et restauration. Plus la taille des bases sera importante, plus la durée des manipulations sera conséquente.

Une migration « test » vous donnera ces précieux renseignements pour indiquer à tous les utilisateurs de TFS / Azure DevOps actuel la durée d’indisponibilité du système.

Typiquement, une installation d’un serveur Azure DevOps se tiendra sur une nouvelle machine virtuelle sur laquelle seront installées les versions requises de Windows Server et de SQL Server. Pour simplifier, nous supposons que cette installation sera mono-serveur. Une migration « test » comprendra les étapes suivantes :

  • Sauvegarde d’une image (snapshot) de la machine virtuelle
  • Sauvegarde des bases du système TFS / Azure DevOps actuel
  • Transfert des bases SQL (fichiers bak) vers la nouvelle machine virtuelle
  • Installation de Azure DevOps Server 2022 sur la nouvelle machine virtuelle
  • Restauration des bases SQL transférées sur la nouvelle machine virtuelle
  • Configuration de Azure DevOps Server 2022 en effectuant la mise à niveau des bases restaurées
  • Restauration du snapshot (VM Windows Server + SQL Server) sur la nouvelle machine virtuelle pour recevoir la vraie migration
Même si vous n’effectuez pas cette migration « test » avec les toutes dernières données des bases, cela vous permet néanmoins de valider techniquement la migration sans interrompre le service. Et surtout de connaître la durée des opérations de sauvegarde, transfert et restauration des bases de données afin d’annoncer aux équipes la durée d’indisponibilité du système lors de la « vraie » migration.

Conseil n°2 : migration « test » sans interrompre le service pour connaître la durée d’indisponibilité du système

migration test pour connaitre la durée d’indisponibilité

Utiliser les sauvegardes planifiées de la console d’administration

Le cœur d’une installation TFS / Azure DevOps, ce sont les bases de données !

On peut toujours réinstaller l’application tiers mais on n’a pas le droit de perdre les bases. Il faut donc toujours disposer de sauvegardes récentes des bases de données SQL dont le nombre varie suivant le nombre de collections :

  • Une base SQL de configuration : TFS_Configuration ou AzureDevOps_Configuration
  • Une base SQL pour chaque collection de l’instance TFS / Azure DevOps : TFS_NomCollection ou AzureDevOps_NomCollection

Pour n collections, il existe donc n+1 bases de données. Ce sont ces n+1 bases de données qu’il convient de sauvegarder, transférer et restaurer dans la cadre d’une mise à niveau vers la dernière version de Azure DevOps Server.

Attention !! Une simple sauvegarde au sens SQL avec génération des fichiers bak par SQL Server Management Studio ne suffira pas !

Puisque ce type de sauvegarde traitera les bases de manière unitaire l’une après l’autre, il risque de se produire une désynchronisation entre les bases, spécifiquement entre la base de configuration et les bases des collections. Le problème est que cette désynchronisation empêchera la restauration des bases sur la nouvelle instance. Et tout sera à recommencer…

Pour s’assurer de la synchronisation, il faut absolument détacher la collection au préalable et ensuite procéder à la sauvegarde de la base au sens SQL. Et il faut bien sûr répéter cette opération pour toutes les collections de l’instance TFS / Azure DevOps.

Le fait de détacher une collection impliquera la synchronisation des données entre la base de cette collection et la base de configuration.

Mais la meilleure solution est d’utiliser les sauvegardes planifiées de la console d’administration de Team Foundation Server ou Azure DevOps Server. La synchronisation entre la base de configuration et les bases de collections sera certaine.

Figure 2 - Configuration des sauvegardes planifiées de la console d’administration Azure DevOps Server

Configuration des sauvegardes planifiées de la console d’administration Azure DevOps Server

Conseil n°3 : Planifier les sauvegardes des bases TFS / Azure DevOps depuis la console d’administration

Planifier les sauvegardes depuis la console Azure DevOps Server
Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *