Phase 6. Tâches de suivi

Vérification de l'état de la migration

Tout d'abord, vérifiez si votre migration a réussi ou échoué.

La façon dont vous vérifiez le statut de votre migration dépend de la manière dont vous avez exécuté la migration.

Si vous avez exécuté la migration à l'aide de GitHub CLI, le processus affichera par défaut l'échec ou la réussite de la migration une fois qu'elle sera terminée. Si la migration a échoué, vous verrez la raison de l'échec.
```
Migration completed (ID: RM_123)! State: SUCCEEDED
```
Si vous avez exécuté la migration à l'aide des données GitHub CLI avec l'argument facultatif --queue-only, le processus s'arrête immédiatement après la mise en file d'attente de la migration et ne vous indique pas si la migration a réussi ou échoué. Vous pouvez vérifier le statut d'une migration à l'aide de la commande wait-for-migration ou en consultant le journal de migration.

Examen du journal de migration

Vous devez passer en revue le journal de migration pour chaque référentiel migré. Les personnes disposant d’un accès en lecture à un dépôt peuvent accéder au journal de migration du dépôt dans GitHub.

Accédez au dépôt migré dans votre organisation de destination.
Sous le nom de votre référentiel, cliquez sur Problèmes.
Cliquez sur le problème avec le titre « Journal de migration ».

Pour plus d’informations, consultez « Accès à vos journaux de migration pour GitHub Enterprise Importer ».

Définition de la visibilité du dépôt

Tous les dépôts sont migrés en tant que dépôts privés par défaut, et seul l’utilisateur qui a exécuté la migration et les propriétaires de l’organisation y ont accès. Si vous ne souhaitez pas que le dépôt soit privé, changez la visibilité.

Vous pouvez changer la visibilité d’un dépôt dans le navigateur. Pour plus d’informations, consultez « Définition de la visibilité du dépôt ».
Vous pouvez également utiliser GitHub CLI pour modifier la visibilité du référentiel à partir de la ligne de commande. Pour plus d’informations, consultez gh repo edit la GitHub CLI documentation.

Par exemple, remplacez YOUR_ORG par le nom de votre organisation, et la commande ci-dessous définira tous les dépôts de l’organisation en visibilité interne.
Bash
```
export ORG=YOUR_ORG
gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal
```
```
export ORG=YOUR_ORG
gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal
```

Récupération de mannequins

Après avoir exécuté une migration avec GitHub Enterprise Importer, toutes les activités utilisateur dans le dépôt migré (à l’exception des commits Git) sont attribuées à des identités d’espace réservé appelées mannequins.

Remarque

Seuls les propriétaires d’organisation peuvent récupérer des mannequins. Si le rôle de migrateur vous a été accordé, contactez un propriétaire d’organisation pour effectuer cette étape.

Décidez si vous voulez récupérer des mannequins.
Planifiez quand vous effectuerez les récupérations.
Récupérez les mannequins. Vous pouvez réattribuer l’historique de chaque mannequin à un membre de l’organisation avec l’interface CLI GitHub ou dans votre navigateur. Si vous utilisez l’interface CLI GitHub, vous pouvez récupérer des mannequins en bloc. Pour plus d’informations, consultez Récupération de modèles pour GitHub Enterprise Importer.
Si l’un des membres ne dispose pas déjà d’un accès approprié au dépôt via son appartenance à l’équipe, donnez-lui l’accès au dépôt. Pour plus d’informations, consultez « Gestion de l’accès d’une personne à un dépôt d’organisation ».

Configuration des listes d’adresses IP autorisées

Si vous avez ajouté les plages d’adresses IP pour GitHub Enterprise Importer à la liste d’adresses IP autorisées de votre organisation de destination, vous pouvez supprimer ces entrées. Si vous avez désactivé les restrictions de la liste d’adresses IP autorisées de votre fournisseur d’identité pour votre entreprise de destination, vous pouvez les réactiver maintenant.

Configurer Azure Pipelines et Azure Boards

Si vous avez utilisé Azure Pipelines ou Azure Boards précédemment et que vous souhaitez continuer à les utiliser avec vos référentiels, ils sont désormais hébergés sur GitHub, vous pouvez suivre ces guides sur Microsoft Learn pour configurer l’extension appropriée.

        [Connecter Azure Pipelines à GitHub](https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github)

        [Configurer l’application Azure Boards pour GitHub](https://learn.microsoft.com/en-us/azure/devops/boards/github/install-github-app)

Prise en charge de vos développeurs dans leur nouvel environnement

Il existe une différence entre Azure DevOps et GitHub qui seraient utiles pour vous et vos développeurs. Partagez Principales différences entre Azure DevOps et GitHub avec eux.

Dans cet article