Migration entre produits GitHub avec GitHub Enterprise Importer

À propos des migrations entre produits GitHub

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

Si vous effectuez une migration entre produits GitHub, par exemple de GitHub Enterprise Server vers GitHub Enterprise Cloud, vous pouvez utiliser ce guide pour planifier et implémenter votre migration et effectuer des tâches de suivi. Pour obtenir la liste complète des chemins de migration pris en charge, consultez « Prise en charge de la migration pour GitHub Enterprise Importer ».

Planification de votre migration

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

• Voulons-nous migrer par organisation ou par dépôt ?
• Quand devons-nous effectuer la migration ?
• Savons-nous ce qui va être migré ?
• Qui va exécuter la migration ?
• Voulons-nous garder une structure d’organisation similaire après la migration ?

Voulons-nous migrer par organisation ou par dépôt ?

Tout d’abord, si votre source et votre destination de migration sont toutes deux GitHub.com, décidez si vous voulez effectuer une migration par organisation ou par dépôt.

Si vous choisissez des migrations par dépôt, seules les données au niveau du dépôt sont migrées. Si vous choisissez la stratégie de migration par organisation, les données au niveau de l’organisation qui sont sélectionnées sont également migrées, y compris les équipes et leur accès aux dépôts.

Toutefois, lorsque vous migrez une organisation, tous les dépôts appartenant à l’organisation source sont migrés en même temps. Vous ne pouvez pas diviser les dépôts en lots ou ignorer la migration des dépôts de l’organisation. Si vous disposez d’un grand nombre de dépôts ou si vous ne pouvez pas tolérer le temps d’arrêt pour tous vos dépôts en même temps, vous risquez de devoir exécuter des migrations de dépôts à la place.

De plus, une migration d’organisation crée une nouvelle organisation dans le compte d’entreprise de destination. Si vous souhaitez migrer des dépôts vers une organisation existante, vous devez exécuter des migrations de dépôts à la place.

Enfin, vous devez être propriétaire du compte d’entreprise de destination pour migrer des organisations. Si vous souhaitez charger une personne qui n’est pas propriétaire d’entreprise d’effectuer vos migrations, elle devra exécuter des migrations de dépôt.

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 référentiels
• Nombre de demandes de tirage
• Nombre de problèmes
• Nombre d’utilisateurs
• Utilisation de projets et de wikis

Le timing de la migration dépend beaucoup du nombre de demandes de tirage et de problèmes dans un dépôt. Si vous souhaitez migrer 1 000 dépôts, que chaque dépôt a 100 demandes de tirage et problèmes 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 et problèmes en moyenne et 5 000 utilisateurs, la migration prendra 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.

1. Passez en revue les données qui sont migrées pour votre source de migration. 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 ?

Déterminez qui exécutera vos migrations et assurez-vous que cette personne dispose de l’accès requis. Vos options varient selon que vous effectuez une migration par organisation ou par dépôt.

Décider qui exécutera les migrations d’organisation

Pour migrer une organisation, vous devez être propriétaire de l’organisation source, ou un propriétaire d’organisation doit vous accorder le rôle de migrateur pour cette organisation.

Vous devez être aussi propriétaire d’entreprise sur le compte d’entreprise de destination. Vous ne pouvez pas accorder le rôle de migrateur pour les comptes d’entreprise.

1. Vérifiez que la personne qui exécutera vos migrations est propriétaire d’entreprise du compte d’entreprise de destination.
2. Si cette personne n’est pas propriétaire de l’organisation source, accordez-lui le rôle de migrateur pour l’organisation. Pour plus d’informations, consultez « Octroi du rôle de migrateur pour GitHub Enterprise Importer ».
3. 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 ».

Décider qui exécutera les migrations de dépôts

Pour migrer un dépôt, vous devez être propriétaire de l’organisation source et de l’organisation de destination, ou un propriétaire d’organisation doit vous accorder le rôle de migrateur pour chaque organisation dont vous n’êtes pas propriétaire.

1. Déterminez si vous souhaitez qu’un propriétaire d’organisation 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 ».

   Remarque : N’oubliez pas d’accorder le rôle de migrateur à la fois pour l’organisation source et l’organisation de destination.

   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 « [AUTOTITLE](/migrations/using-github-enterprise-importer/preparing-to-migrate-with-github-enterprise-importer/managing-access-for-github-enterprise-importer) ».

Voulons-nous garder une structure d’organisation similaire après la migration ?

Ensuite, déterminez si vous voulez garder une structure organisationnelle similaire après la migration ou non. Si vous souhaitez répartir votre effort de migration sur plusieurs lots, cela vous aidera à déterminer vos lots. Si vous envisagez de conserver une correspondance un-à-un entre les organisations de votre source et de votre destination, nous vous recommandons d’effectuer des migrations en lots par organisation. Il s’agit de l’approche la plus simple, en particulier si vous migrez à partir de GitHub.com, car vous pouvez migrer une organisation entière avec une seule commande. Si vous effectuez une migration à partir d’une autre source, GitHub CLI peut générer un script pour migrer tous les dépôts d’une même organisation.

Si vous avez l’intention de modifier votre structure organisationnelle, envisagez d’autres facteurs de traitement par lots. Vous pouvez faire des lots de dépôts appartenant à des équipes similaires ou à une division, ou vous pouvez faire des lots par organisation de destination. Nous recommandons de faire des lots par équipe si possible. Si vous faites des lots par division ou par organisation de destination, vous augmentez le nombre de parties prenantes impliquées, ce qui peut entraîner des fenêtres de temps plus courtes pour vos migrations.

Même si vous modifiez votre structure organisationnelle, vous pouvez toujours préparer un script pour votre migration. Utilisez la commande GitHub CLI, puis déplacez les lignes de chaque dépôt dans différents scripts en fonction des besoins.

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.

Pour les migrations de dépôts, 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. Si vous exécutez une migration de dépôt, créez une organisation de test pour vos migrations d’essai.
2. Si votre organisation source 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 ».
3. Exécutez les migrations d’essai. Pour plus d’informations, consultez « Préparation à l’exécution d’une migration avec GitHub Enterprise Importer ».
4. Effectuez les tâches de suivi décrites ci-dessous pour les migrations d’essai.
5. Demandez aux utilisateurs de valider les résultats des migrations.
6. 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 ».
7. Si vous exécutez une migration de dépôt et que vous souhaitez migrer les paramètres GitHub Advanced Security, activez GitHub Advanced Security pour l’organisation de destination. Pour plus d’informations, consultez « Gestion des paramètres de sécurité et d’analyse pour votre organisation ».
8. Exécutez vos migrations de production. Pour plus d’informations, consultez « Migration de dépôts avec GitHub Enterprise Importer » ou « Migration d’organisations avec GitHub Enterprise Importer ».
9. 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
• Migration des objets Git LFS
• Définition de la visibilité du dépôt
• Configuration de GitHub Actions
• Configuration des listes d’adresses IP autorisées
• Gestion de GitHub Advanced Security
• Activation des webhooks
• Réinstallation des GitHub Apps
• Recréation des équipes
• Récupération des mannequins

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 ».

Migration des objets Git LFS

GitHub Enterprise Importer ne migre pas les objets Git LFS. Si le dépôt source utilise Git LFS, vous pouvez pousser manuellement les objets Git LFS vers le dépôt migré localement. Pour plus d’informations, consultez « Duplication d’un dépôt ».

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 de GitHub Actions

Si vous utilisez GitHub Actions dans un dépôt, vos workflows sont automatiquement migrés dans le cadre du dépôt Git.

Pendant le processus de migration, GitHub Actions est désactivé pour tous les dépôts migrés afin d’éviter le déclenchement accidentel de workflows, mais GitHub Actions est réactivé à la fin de la migration.

Si vous utilisiez des exécuteurs auto-hébergés ou des secrets chiffrés, vous devez les reconfigurer.

1. Si vous utilisez des exécuteurs auto-hébergés, reconfigurez vos exécuteurs.

   • Ajoutez des exécuteurs au dépôt, à l’organisation ou à l’entreprise appropriés. Pour plus d’informations, consultez « Ajout d’exécuteurs auto-hébergés ».
   • Pour utiliser des exécuteurs au niveau de l’organisation ou de l’entreprise, mettez à jour vos workflows. Pour plus d’informations, consultez « Utilisation d’exécuteurs auto-hébergés dans un workflow ».

2. Rajoutez tous les secrets chiffrés.

   • Pour utiliser le navigateur, consultez « Secrets chiffrés ».
   • Pour utiliser GitHub CLI, consultez gh secret dans la documentation GitHub CLI.

3. Reconfigurez les environnements. Pour plus d’informations, consultez « Utilisation d’environnements pour le déploiement ».

Configuration des listes d’adresses IP autorisées

Si vous avez ajouté les plages d’adresses IP pour GitHub Enterprise Importer aux listes d’adresses IP autorisées de vos organisations sources ou 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 ».

Gestion de GitHub Advanced Security

Si vous avez activé GitHub Advanced Security pour l’organisation de destination avant la migration des dépôts, les paramètres des fonctionnalités individuelles ont été migrés. Si ce n’est pas le cas, vous devez réactiver les fonctionnalités individuelles après la migration. Pour plus d’informations, consultez « Gestion des paramètres de sécurité et d’analyse pour votre dépôt ».

Il existe des étapes post-migration supplémentaires pour chaque fonctionnalité.

Secret scanning

Lorsque l’analyse des secrets est activée pour le dépôt de destination, une analyse de l’ensemble du dépôt est effectuée. Une fois l’analyse terminée, toutes les alertes sont renseignées, mais sans états de correction.

Vous pouvez utiliser l’API REST pour mettre à jour les alertes afin de mettre en miroir toutes les corrections dans le dépôt source. Pour plus d’informations, consultez « Analyse de secrets » dans la documentation de l’API REST.

L’utilisateur associé à ces corrections mises à jour sera l’utilisateur propriétaire du personal access token utilisé pour les appels d’API, et non l’utilisateur qui a corrigé l’alerte dans le dépôt source, et la date associée à la correction sera la date de l’appel d’API, et non la date à laquelle l’alerte a été corrigée dans le dépôt source.

Code scanning

Les alertes d’Code scanning ne sont pas migrées par GitHub Enterprise Importer. Toutefois, les alertes sont disponibles sous forme de données SARIF dans le dépôt source. Vous pouvez utiliser l’API REST pour charger ces données dans le dépôt de destination. Pour plus d’informations, consultez « Analyse du code » dans la documentation de l’API REST.

Les alertes d’Code scanning qui sont renseignées de cette façon diffèrent des alertes d’origine du dépôt source.

• Les alertes incluent uniquement la détection et le dernier état de l’alerte, et non la chronologie complète du dépôt source.
• Les alertes sont identifiées uniquement comme open ou fixed. D’autres états de correction, tels que dismissed et reopened, seront perdus.
• Les dates de tous les événements de l’alerte sont la date de l’appel d’API, et non les dates auxquelles les événements se sont produits à l’origine dans le dépôt source.
• Tous les acteurs, comme le créateur de l’alerte, deviennent propriétaires du personal access token utilisé pour l’appel d’API.

Dependabot alerts

Lorsque les Dependabot alerts et le graphe des dépendances sont activés, les Dependabot alerts sont recréés à partir de l’état actuel de la branche par défaut. Les états de correction de ces alertes ne sont pas migrés, ni aucune des alertes précédentes.

Vous devrez rajouter les secrets chiffrés pour Dependabot. Pour plus d’informations, consultez « Configuration de l’accès aux registres privés pour Dependabot ».

Activation des webhooks

Tous les webhooks actifs du dépôt source sont migrés. Toutefois, les webhooks migrés sont désactivés par défaut. Vous pouvez réactiver ces webhooks dans les paramètres du dépôt.

1. Accédez aux paramètres du dépôt migré.
2. Dans la section « Code et automatisation » de la barre latérale, cliquez sur Webhooks.
3. À droite du webhook que vous souhaitez activer, cliquez sur Modifier.
4. Si vous utilisiez un jeton secret pour sécuriser le webhook, sous « Secret », rajoutez le secret.
5. En bas de la page, sélectionnez Actif
6. Cliquez sur Mettre à jour le webhook.

Réinstallation des GitHub Apps

Si vous aviez des GitHub Apps installées sur le dépôt source, vous devez les réinstaller sur le dépôt migré. Pour plus d’informations, consultez « Installing your own GitHub App ».

Recréation des équipes

Si vous avez effectué une migration par organisation, vous devez uniquement rétablir les appartenances aux équipes. Si vous avez migré par dépôt, vous devez recréer les équipes, accorder à ces équipes l’accès aux dépôts, puis rétablir les appartenances aux équipes.

Recréation des équipes pour les migrations d’organisation

Les équipes et leur accès au dépôt sont migrés dans le cadre d’une migration d’organisation, mais pas les appartenances aux équipes. Après votre migration, vous devez ajouter des utilisateurs aux équipes migrées.

Nous vous recommandons vivement d’utiliser la synchronisation d’équipe pour gérer les appartenances aux équipes via votre fournisseur d’identité (IdP). Pour plus d’informations, consultez « Configuration du provisionnement SCIM pour Enterprise Managed Users » ou, pour les entreprises qui n’utilisent pas Enterprise Managed Users, « Gestion de la synchronisation d’équipe pour les organisations de votre entreprise ».

Sinon, vous pouvez ajouter manuellement des membres à votre organisation, puis ajouter les membres de l’organisation aux équipes. Pour plus d’informations, consultez « Ajout de membres d’une organisation à une équipe ».

Recréation des équipes pour les migrations de dépôts

Les équipes ne sont pas migrées dans le cadre d’une migration de dépôt. Vous devez recréer manuellement les équipes et accorder à chaque équipe l’accès au dépôt.

1. Recréez les équipes. Pour plus d’informations, consultez « Création d’une équipe ».
2. Ajoutez des membres d’organisation aux équipes. Pour plus d’informations, consultez « Ajout de membres d’une organisation à une équipe ».
3. Donnez à chaque équipe l’accès au dépôt. Pour plus d’informations, consultez « Gestion de l’accès de l’équipe à un dépôt de l’organisation ».

Récupération des 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 ».