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

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.

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

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.

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.