Migration à partir d’Azure DevOps avec GitHub Enterprise Importer

À propos des migrations à partir d’Azure DevOps

Avec GitHub Enterprise Importer, vous pouvez migrer vers GitHub Enterprise Cloud dépôt par dépôt. Pour plus d’informations, consultez « À propos de GitHub Enterprise Importer ».

Si vous effectuez une migration à partir d’Azure DevOps (ADO), vous pouvez utiliser ce guide pour planifier et implémenter votre migration, puis effectuer des tâches de suivi.

Les entreprises qui migrent d’ADO vers GitHub suivent généralement une approche en plusieurs phases.

1. Migrez les dépôts d’ADO vers GitHub.
2. Migrez les pipelines d’Azure Pipelines vers GitHub Actions.
3. Migrez les ressources restantes, telles que les tableaux et les artefacts, d’ADO vers GitHub.

Ce guide vous aide à accomplir la première phase, à savoir la migration des dépôts vers GitHub, et suppose que vous utilisez l’ADO2GH extension of the GitHub CLI.

Planification de votre migration

Pour planifier votre migration, posez-vous les questions suivantes.

• Quand devons-nous effectuer la migration ?
• Savons-nous ce qui va être migré ?
• Qui va exécuter la migration ?
• Quelle structure organisationnelle voulons-nous dans GitHub ?

Quand devons-nous effectuer la migration ?

Déterminez votre planning qui dictera en grande partie votre approche. La première étape pour déterminer votre planning consiste à obtenir un inventaire de ce que vous devez migrer. Pour collecter ces données, utilisez l’Analyseur de migration GitHub. Cet outil open source génère un rapport qui détaille la quantité de données à migrer pour une organisation.

• Nombre de dépôts
• Nombre de demandes de tirage

Le timing de la migration dépend beaucoup du nombre de demandes de tirage dans un dépôt. Si vous souhaitez migrer 1 000 dépôts, que chaque dépôt a 100 demandes de tirage en moyenne et que seuls 50 utilisateurs ont contribué aux dépôts, votre migration sera probablement très rapide. Si vous souhaitez migrer seulement 100 dépôts, mais que les dépôts ont chacun 75 000 demandes de tirage en moyenne et 5 000 utilisateurs, la migration prendra beaucoup plus de temps et demandera beaucoup plus de planification et de test.

After you use the analyzer, you can weigh your inventory data against your desired timeline. If your organization can withstand a higher degree of change, then you might be able to migrate all your repositories at once, completing your migration efforts in a few days. However, you may have various teams that are not able to migrate at the same time. In this case, you might want to batch and stagger your migrations to fit the teams' timelines, extending your migration effort.

1. Use the GitHub Migration Analyzer, then review your migration inventory.
2. To understand when teams can be ready to migrate, interview stakeholders.
3. Fully review the rest of this guide, then decide on a migration timeline.

Savons-nous ce qui va être migré ?

Assurez-vous que vous et vos parties prenantes savez quelles données peuvent être migrées par GitHub Enterprise Importer.

Pour les migrations à partir d’ADO, GitHub Enterprise Importer migre uniquement les dépôts Git, y compris les demandes de tirage et certaines stratégies de branche. Toutes les autres ressources, telles que les pipelines, les éléments de travail, les artefacts, les plans de test, les mises en production et les tableaux de bord, restent dans ADO.

Étant donné que les autorisations fonctionnent différemment dans GitHub que dans ADO, GitHub Enterprise Importer ne tente pas de migrer les autorisations de dépôt à partir d’ADO. Pour plus d’informations, consultez « Configuration des autorisations ».

Les hooks de service ne sont pas migrés à partir d’ADO, donc vous devez les recréer séparément.

1. Passez en revue les données qui sont migrées à partir d’Azure DevOps. Pour plus d’informations, consultez « Prise en charge de la migration pour GitHub Enterprise Importer ».
2. Dressez la liste des données que vous devez migrer ou recréer manuellement.

Qui va exécuter la migration ?

Pour migrer un dépôt, vous devez être propriétaire de l’organisation de destination, ou un propriétaire d’organisation doit vous accorder le rôle de migrateur.

1. Déterminez si vous souhaitez qu’un propriétaire de l’organisation de destination effectue vos migrations, ou si vous devez accorder le rôle de migrateur à quelqu’un d’autre.
2. Si vous avez choisi d’accorder le rôle de migrateur, choisissez la personne ou l’équipe à laquelle vous allez accorder le rôle.
3. Accordez le rôle de migrateur à la personne ou à l’équipe. Pour plus d’informations, consultez « Octroi du rôle de migrateur pour GitHub Enterprise Importer ». 1. Vérifiez que la personne a correctement configuré les personal access token pour répondre à tous les besoins d’accès. Pour plus d’informations, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».

Quelle structure organisationnelle voulons-nous dans GitHub ?

Ensuite, planifiez la structure organisationnelle que vous allez créer dans GitHub. ADO et GitHub ont différentes façons d’organiser le travail d’une entreprise.

• ADO : Organisation > projet d’équipe > dépôts
• GitHub : Entreprise > organisation > dépôts

Après la migration vers GitHub, vous ne devez avoir qu’un seul compte d’entreprise et un petit nombre d’organisations appartenant à cette entreprise. Chaque organisation d’ADO doit correspondre à une seule organisation dans GitHub. Nous vous déconseillons de créer une organisation dans GitHub pour chaque projet d’équipe sur ADO.

Cela peut donner une grande liste de dépôts non groupés au sein de chaque organisation. Toutefois, vous pouvez gérer l’accès aux groupes de dépôts en créant des équipes. Pour plus d’informations, consultez « À propos des équipes ».

Si vous souhaitez répartir votre effort de migration sur plusieurs lots, la nouvelle structure peut vous aider à déterminer vos lots. Si vous avez plusieurs organisations dans ADO et que les dépôts de chaque organisation constituent des lots de taille raisonnable, envisagez de procéder par organisation. Vous pouvez utiliser GitHub CLI pour générer un script de migration pour toute une organisation sur ADO.

1. Déterminez la structure de votre nouvelle organisation.
2. Déterminez si vous devez diviser votre migration en plus petites parties.
3. Si c’est le cas, décidez de la façon dont vous souhaitez diviser vos migrations.

Exécution de vos migrations

Une fois votre planification terminée, vous pouvez démarrer les migrations. Pour vous aider à détecter les problèmes susceptibles d’être propres à votre entreprise pendant et après la migration, nous vous recommandons vivement d’effectuer des exécutions d’essai de toutes les migrations. Après avoir résolu les problèmes détectés par les exécutions d’essai, vous pouvez exécuter vos migrations de production.

Les migrations d’essai vous aident à déterminer plusieurs informations critiques.

• Si la migration d’un dépôt donné peut s’effectuer correctement
• Si vous pouvez ramener le dépôt à un état où vos utilisateurs peuvent commencer à travailler
• La durée d’exécution d’une migration, ce qui est utile pour planifier les migrations et définir les attentes des parties prenantes

Les exécutions d’essai ne demandent pas beaucoup de temps de coordination. GitHub Enterprise Importer n’a jamais besoin de temps d’arrêt de la part des utilisateurs d’un dépôt en cours de migration. Toutefois, nous vous recommandons d’interrompre le travail pendant les migrations de production pour vous assurer que de nouvelles données ne sont pas créées pendant la migration, qui seraient alors manquantes dans le dépôt migré. Ce n’est pas un problème pour les migrations d’essai, donc elles peuvent avoir lieu à tout moment. Pour réduire le temps nécessaire à l’exécution de vos migrations d’essai, vous pouvez planifier les lots de vos exécutions d’essai les unes à la suite des autres. Les utilisateurs de ces dépôts peuvent ensuite valider les résultats quand ils veulent.

Nous vous recommandons de créer une organisation de test à utiliser comme destination pour vos migrations d’essai. Vous pouvez utiliser une seule organisation pour toutes les exécutions d’essai, ou vous pouvez créer une organisation de test pour chaque organisation de destination prévue. Pensez à inclure -sandbox à la fin des noms d’organisation pour clarifier que les organisations sont destinées uniquement à la validation de la migration et non à la production. Vous pouvez supprimer les organisations de test une fois que vous avez terminé.

1. Créez une organisation de test pour vos migrations d’essai.
2. Exécutez les migrations d’essai. Pour plus d’informations, consultez « Préparation à l’exécution d’une migration avec GitHub Enterprise Importer ».
3. Effectuez les tâches de suivi décrites ci-dessous pour les migrations d’essai.
4. Demandez aux utilisateurs de valider les résultats des migrations.
5. Résolvez les problèmes découverts par vos migrations d’essai. 1. Si votre destination utilise des listes d’adresses IP autorisées, configurez la liste pour autoriser l’accès par GitHub Enterprise Importer. Pour plus d’informations, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».
6. Exécutez vos migrations de production. Pour plus d’informations, consultez « Migration de référentiels d’Azure DevOps vers GitHub Enterprise Cloud ».
7. Optionally, delete the test organization.

Exécution des tâches de suivi

À la fin de chaque migration, vous devez effectuer des tâches supplémentaires avant que le dépôt soit prêt pour le travail.

• Examen du journal de migration
• Définition de la visibilité du dépôt
• Configuration des autorisations
• Récupération des mannequins
• Configuration des listes d’adresses IP autorisées

Examen du journal de migration

Tout d’abord, passez en revue le journal de migration pour chaque dépôt migré. Pour plus d’informations, consultez « Accès à vos journaux de migration pour GitHub Enterprise Importer ».

Si des éléments spécifiques du dépôt n’ont pas pu être migrés, un avertissement s’affiche dans le journal de migration.

1. Passez en revue vos journaux de migration.
2. Passez en revue les avertissements de chaque journal et assurez-vous qu’aucun ne bloque la migration. Pour plus d’informations, consultez « Résolution des problèmes de votre migration avec 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, 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 changer la visibilité d’un dépôt à partir de la ligne de commande. Vous pouvez même ajouter cette commande au script qui a été généré pour exécuter vos migrations. Pour plus d’informations, consultez gh repo edit dans la documentation GitHub CLI.

Configuration des autorisations

Étant donné que les autorisations fonctionnent différemment dans GitHub que dans ADO, GitHub Enterprise Importer ne tente pas de migrer les autorisations de dépôt à partir d’ADO.

Si vous avez utilisé l’interface CLI ADO2GH, GitHub Enterprise Importer crée deux équipes dans GitHub pour chaque projet d’équipe dans ADO. Chaque équipe dispose d’un niveau d’accès différent à tous les dépôts provenant du projet d’équipe.

Équipe	Accès aux dépôts migrés
TEAM-PROJECT-Chargés de maintenance	Gestionnaire
TEAM-PROJECT-Administrateurs	Admin

Pour donner accès aux dépôts migrés, vous pouvez ajouter des personnes à ces équipes. Vous pouvez le faire manuellement dans GitHub, ou si vous avez choisi de lier les équipes à des groupes Azure Active Directory (AAD) pendant votre migration, en gérant l’appartenance au groupe dans AAD. Pour plus d’informations sur la gestion manuelle de l’appartenance à une équipe, consultez « Ajout de membres d’une organisation à une équipe ».

Si vous n’utilisez pas l’interface CLI ADO2GH ou si vous avez besoin d’une configuration d’autorisations plus avancée que celle par défaut, configurez des autorisations pour vos dépôts migrés. Vous pouvez modifier le script de migration en fonction de vos besoins, ou vous pouvez configurer manuellement des autorisations après votre migration. Pour plus d’informations sur la gestion de l’accès aux dépôts dans GitHub, consultez « Rôles de dépôt pour une organisation ».

1. Déterminez la structure d’autorisations dont vous avez besoin dans GitHub.
2. Si elle est différente de celle par défaut, planifiez la configuration de l’appartenance à l’équipe et des autorisations.

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.

Vous pouvez réattribuer l’historique de chaque mannequin à un membre de l’organisation en envoyant une invitation d’attribution avec GitHub CLI ou dans votre navigateur. Si vous utilisez GitHub CLI, vous pouvez récupérer des mannequins en bloc. Pour plus d’informations, consultez « Récupération de mannequins pour GitHub Enterprise Importer ».

1. Décidez si vous voulez récupérer des mannequins.
2. Planifiez quand vous effectuerez les récupérations.
3. Récupérez les mannequins.
4. 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.

Pour plus d’informations, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».