Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Une fois la migration terminée, un e-mail est envoyé au propriétaire de l’organisation et à ce stade, toute personne ayant accès peut se connecter à l’organisation Azure DevOps Services nouvellement migrée. Toutefois, avant de rendre l’organisation disponible pour tous les utilisateurs, vous devez effectuer les tâches courantes répertoriées dans cet article.
Valider le contenu migré
Immédiatement après la disponibilité de l’organisation, vérifiez le contenu et la configuration migrés pour vous assurer que tous les composants critiques ont été correctement migrés. Vos administrateurs de collection de projets doivent mener ce processus et couvrir tous les principaux domaines de votre collection. Nous vous recommandons de valider les éléments suivants :
- Code source : vérifiez que tous les référentiels ont été migrés correctement et sont accessibles.
- Historique des builds : vérifiez que l’historique de build complet est intact et correspond aux attentes.
- Chemins d'accès à la zone : vérifiez que tous les chemins d'accès à la zone sont présents et correctement structurés.
- Éléments de travail : passez en revue un échantillon représentatif d’éléments de travail pour confirmer l’intégrité et les relations des données.
- Autorisations et sécurité : vérifiez que les autorisations utilisateur, les groupes et les contrôles d’accès sont correctement configurés. Selon la façon dont les utilisateurs sont configurés dans votre serveur Azure DevOps, ils peuvent ne pas apparaître dans le hub Utilisateurs de votre nouvelle organisation tant qu’ils ne se connectent pas pour la première fois. Si des utilisateurs manquent après la migration, demandez-leur de se connecter puis revérifiez leur statut.
- Connexions de service et pipelines : vérifiez que les connexions de service et les configurations de pipeline sont fonctionnelles.
- Tableaux de bord et widgets : vérifiez que les tableaux de bord s’affichent correctement et que les widgets affichent les données attendues.
Cette validation permet d’identifier les données manquantes, incomplètes ou mal configurées avant d’ouvrir l’organisation à votre base d’utilisateurs plus large, en garantissant une transition fluide et en réduisant les interruptions.
Important
Ne supprimez pas ou ne détruisez pas vos données locales ou désaffectez les systèmes tant que vous n’avez pas confirmé que toutes les données et fonctionnalités attendues existent dans l’organisation migrée.
Renommer l’organisation (facultatif)
Si vous avez créé une organisation d’espace réservé avec le nom souhaité pendant la phase de prise en main, vous pouvez maintenant renommer votre organisation migrée pour la remplacer. Cette étape est nécessaire uniquement si c’est votre migration finale et que vous souhaitez utiliser un nom d’organisation spécifique. Pour plus d’informations, consultez Renommer votre organisation.
Configurer la facturation
Pour payer des utilisateurs ou des services dans Azure DevOps, comme les agents de génération et de déploiement hébergés, vous devez configurer la facturation pour votre organisation. Si vous migrez plusieurs regroupements, vous devez vous assurer que toutes vos organisations sont configurées pour la facturation avec le même abonnement Azure et que votre abonnement est activé pour la facturation multi-organisation. Vous pouvez ensuite affecter autant d’utilisateurs de base que vous avez besoin gratuitement pendant le mois calendrier dans lequel vous exécutez la migration.
Configurer les agents de build
Si vous avez utilisé des serveurs de build ou de déploiement automatisés dans votre environnement Azure DevOps Server, vous pouvez les connecter à votre organisation Azure DevOps Services. Dans le cadre de la migration, toutes vos définitions de build ont été migrées, mais vous devez reconfigurer les agents et les pools par rapport à votre nouvelle organisation Azure DevOps Services.
Pour plus d’informations, consultez Agents Azure Pipelines.
Si vous envisagez d’utiliser vos agents de build privés locaux existants, vous devez effacer leur cache, ce qui garantit que vous ne rencontrez aucun problème de build lié aux anciens pointeurs TFVC (Team Foundation Version Control) ou Git vers votre collection locale. Pour plus d’informations, consultez l’actualisation des caches sur les ordinateurs clients.
Conseil / Astuce
Si vous avez utilisé Release Management dans Azure DevOps Server, vos pipelines de mise en production et vos données d’historique ont été migrés. Toutefois, comme pour les builds, vous devez reconfigurer vos agents (relier à nouveau) et vos pools en fonction de la nouvelle organisation.
Utiliser Azure Artifacts
Azure Artifacts est inclus dans Azure DevOps Services pour tous les utilisateurs disposant d’une licence de base. Il n’est pas nécessaire d’installer une extension. Vos données Azure Artifacts doivent être disponibles après la migration. Pour plus d’informations, consultez la vue d’ensemble d’Azure Artifacts.
Personnaliser Azure Boards
Si vous disposez d’une connexion GitHub Enterprise Server existante associée à votre serveur Azure DevOps, elle ne fonctionne pas comme prévu. Les éléments de travail mentionnés dans GitHub peuvent être retardés ou ne s’affichent jamais dans Azure DevOps Services. Ce problème se produit car l’URL de rappel associée à GitHub n’est plus valide.
Pour résoudre le problème, tenez compte des tâches suivantes :
- Supprimez et recréez la connexion : Supprimez et recréez la connexion au dépôt GitHub Enterprise Server. Suivez la séquence d’étapes fournies dans la documentation Connect de Azure Boards.
-
Corrigez l’URL du webhook : Accédez à la page des paramètres de dépôt de GitHub et modifiez l’URL du webhook pour pointer vers l’URL de l’organisation Azure DevOps Services migrée :
https://dev.azure.com/{OrganizationName}/_apis/work/events?api-version=5.2-preview.
Pour plus d’informations, consultez Configurer et personnaliser Azure Boards.
Révision des autorisations
Votre organisation comprend cinq utilisateurs gratuits disposant d’un accès de base . Pour plus d’informations, consultez Ajouter des utilisateurs de l'organisation et gérer l'accès.
Avertir vos équipes
Une fois que vos builds sont en cours d’exécution et que l’abonnement aux licences est configuré, nous vous recommandons d’ouvrir l’organisation à tous les utilisateurs à des fins de validation. Ensuite, les utilisateurs individuels peuvent s’assurer que tout le contenu est en place, dispose du niveau d’accès approprié et qu’ils peuvent extraire du code.
Les utilisateurs de TFVC avec des espaces de travail locaux doivent remapper leurs espaces de travail en fonction de la nouvelle organisation, et les utilisateurs de Git doivent reconfigurer leurs distants pour extraire le code.