La migration Azure DevOps entre deux tenants Azure

Joffrey Nurit

il y a 3 ans

Une migration, ce n’est jamais facile à aborder, alors une migration entre tenants Azure, c’est rarement le sujet sur lequel on a un gros retour d’expérience. Et si la migration concerne un sujet central comme Azure DevOps, ça peut rapidement mettre la pression.

Un petit tutoriel pourra certainement rassurer les plus frileux. Vous y trouverez la procédure que je recommande, des liens vers les documentations officielles, et surtout des conseils sur les déboires que vous pouvez rencontrer !

Bonne lecture.

Table des matières

Toggle

Les prérequis d’une migration Azure DevOps

Les prérequis sont donnés directement sur le tutoriel officiel. Mais d’expérience, j’y apporterais un petit changement :

Si possible, assurez-vous d’avoir la possession des deux comptes importants, à savoir le owner de l’organisation actuelle, et l’utilisateur de l’organisation vers laquelle on fait la migration.
Les deux comptes doivent être Project Collection Administrator.
Les deux comptes doivent être en guest sur le tenant de l’autre. C’est obligatoire pour le compte qui va effectuer la migration, mais il va être important aussi que le Owner soit en guest sur le tenant vers lequel on migre ! C’est ce point qui m’a fait défaut dans le tutoriel officiel.
Si vous utilisez des agents Azure DevOps On prémisse, pensez à les supprimer avant. On voit ça dans l’étape d’après.

Vous devriez avoir quelque chose comme ça in fine

Suppression des agents Azure DevOps

Suppression par l’invite de commande

C’est la manière la plus classique de faire. Mais elle ne fonctionne que si vous avez bien suivi ce tutoriel et que vous le faites AVANT d’effectuer la migration.

Connectez-vous à la machine qui héberge l’agent, puis tapez la ligne de commande suivante dans le répertoire de l’agent (par défaut : C:\agent).

 .\config.cmd remove

La procédure de désinstallation va s’enclencher. Elle va vous demander un PAT, que vous devrez surement générer. Je vous invite à consulter la fin de l’article à ce sujet.

Suppression manuelle

Cette méthode peut être particulièrement utile, surtout si vous avez suivi ce tutoriel en oubliant de supprimer les agents par la ligne de commande. Si vous effectuez cette étape à la fin de ce tutoriel, vous serrez bloqué, car la liaison entre votre agent et l’ancien tenant sera détruite. On ne peut reconfigurer un agent, et la suppression normale n’étant plus possible, ça devient compliqué.

Heureusement, il existe une méthode. En fait, le script de suppression de l’agent effectue trois actions :

Il décommissionne le service dans Azure DevOps
Il supprime le service Windows
Il détruit les configurations actuelles

Récupération du nom de service

On va procéder dans l’ordre et détruire le service Windows avant tout. Pour cela, il nous faut son nom, qui est aisément trouvable dans Azure DevOps.

*Vous pourrez récupérer le nom du service dans l’Agent Pool de l’organisation.*

Suppression du service Windows

Une fois le nom de l’agent récupéré, vous pouvez exécuter la commande powershell suivante (pour les agents sur Windows).

sc delete [AgentName]

Destruction des fichiers de configuration de l’agent

Maintenant que le service ne tourne plus, il va être possible de supprimer les fichiers de configuration qui nous gênent. Pensez à activer l’option pour voir les fichiers cachés.

Il vous suffit tout simplement de supprimer les fichiers « .agent », « .credentials » et « .credentials_rsaparams ».

Détruire l’agent sur Azure DevOps (optionnel)

Cette étape est optionnelle, en ce sens que si vous ne détruisez pas les agents répertoriés sur Azure Devops, il vous proposera un « replace » lors de la configuration de ce dernier. Il vous suffira alors d’accepter pour que la liaison soit modifiée sur Azure DevOps.

Maintenant que l’agent n’est plus un service Windows opérationnel, il suffit de le décommissionner sur Azure DevOps. Vous pouvez retourner sur la liste des agents où vous aviez récupéré le nom, et cliquer sur l’option « delete ».

Vos agents seront prêts à être reconfigurés sur le nouveau tenant !

La migration d’Azure DevOps

Bon, là on rentre dans le cœur du sujet. Le tutoriel et les étapes de migration sont très claires sur le tutoriel officiel, je ne vais pas avoir d’autres choses à faire que vous indiquer de le suivre jusqu’au bout !

Il y a néanmoins deux trois configurations intéressantes à faire après coup, qui ne sont pas répertoriées sur le tuto, donc je vous laisse revenir sur cette page une fois terminé ;).

Mettre le Owner sur le bon tenant

Si vous avez correctement suivi le début de ce tutoriel, et que vous avez pensé à avoir les deux comptes présents dans les deux tenant, vous ne devriez avoir aucun mal sur cette étape.

En effet, une fois la migration effectuée par votre compte de destination, Azure DevOps a changé de tenant. Mais le owner reste toujours votre ancien compte ! Si vous ne l’avez pas ajouté sur le tenant de destination en tant que guest, vous allez être dans une impasse. Car c’est le owner actuel qui peut changer le owner du service. Or, si il n’est pas présent sur le tenant de destination, ce dernier ne pourra pas se connecter.

Une fois que le owner est bien présent sur le tenant de destination, il vous suffit de faire changer le owner pour y attribuer le nouveau compte de destination.

Renommage de l’organisation Azure DevOps

Votre Azure DevOps est prêt à être utilisé, parfait ! Malgré tout, il est possible qu’il manque un petit détail: est-ce que le nom de l’organisation est toujours le bon?

Lorsqu’on crée un service Azure DevOps, on choisit un nom d’organisation. Naturellement, on met souvent le nom de la société. Or, migration de tenant, ça veut souvent dire migration de société. Et il est possible que l’on souhaite effacer tout lien avec l’ancienne société.

Pour cela, maintenant que la propriété est attribuée au bon compte, vous pouvez changer le nom de l’organisation. Attention cependant, cela a des conséquences sur les urls d’accès, qui sont précisées en warning lors du changement. Les développeurs n’auront pas automatiquement le nouveau lien du dépôt, et devront donc effectuer une modification sur leurs fichiers de configuration Git !

Si vous souhaitez faire le changement de nom, vous pouvez utiliser cette documentation Microsoft. L’option est disponible au même endroit que le transfert de propriété.

Changement des liens sur les postes développeurs

Vous avez effectué le changement de nom de l’organisation? Il va falloir alors mettre à jour les liens de vos différents projets vers la nouvelle URL du dépot.

Pour cela, vous pouvez suivre le lien suivant, qui vous montre un exemple avec Visual Studio.

Reconfiguration des agents On Premise

Voici la dernière étape, si vous utilisez des agents On premise. Maintenant que la migration a bien été effectuée, il faut les reconfigurer. Vous pouvez suivre le tutoriel officiel de cette section ici.

Génération du PAT

Pour cela, on doit commencer par générer un Personnal Access Token (PAT). C’est une clé API qui permet aux services externes de se connecter à Azure DevOps, avec des droits limités à ceux que vous avez choisis. En l’occurrence, c’est l’agent qui va se connecter à Azure DevOps pour configurer la liaison entre eux. Ce token a besoin de très peu de droits (agent pool read & write), et une durée de vie très courte (le temps de la configuration des agents).