Share via


Terminez les tâches post-migration

Une fois la migration terminée, un e-mail est envoyé au propriétaire d’organisation et à ce stade, toute personne disposant d’un 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.

Diagramme de l’étape post-migration mise en surbrillance des sept étapes de migration.

Spot case activée

Immédiatement après la disponibilité de l’organisation, prenez une petite équipe et placez les case activée sur l’organisation. Nous recommandons que cette équipe se compose des administrateurs de collection de projets. Cette case activée ne devrait pas être approfondie, mais plutôt s’assurer que les pièces majeures de votre collection ont été apportées.

  • Code source : vérifiez que vos référentiels de code source ont été migrés correctement.
  • Historique des builds : vérifiez que votre historique de build l’a fait.
  • Chemins de zone : vérifiez que tous les chemins d’accès de zone sont toujours présents.

Ces case activée rapides vous aident à intercepter les données manquantes ou incomplètes avant d’ouvrir l’organisation à l’ensemble de votre base d’utilisateurs.

Renommer l’organisation (facultatif)

Dans la phase de prise en main, vous avez peut-être déjà créé des organisations avec les noms d’organisation Azure DevOps Services finaux que vous souhaitez utiliser. S’il s’agit de votre migration finale, vous pouvez renommer votre organisation Azure DevOps Services nouvellement migrée en ce nom souhaité. 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 build 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 des 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 les 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

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 avec les builds, vous devez reconfigurer vos agents (lier à nouveau) et les pools sur la nouvelle organisation.

Utiliser Azure Artifacts

Azure Artifacts est inclus avec 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 :

  • Supprimer et recréer la connexion : supprimez et recréez la connexion au dépôt GitHub Enterprise Server. Suivez la séquence d’étapes fournie dans Se connecter à partir d’Azure Boards documentation.
  • Corrigez l’URL du webhook : accédez à la page des paramètres de référentiel 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 remappper leurs espaces de travail sur la nouvelle organisation, et les utilisateurs Git doivent reconfigurer leurs distances pour extraire du code.

Si quelque chose manque à l’organisation migrée, contactez le support technique.

Étapes suivantes