Vue d’ensemble d’une migration entre produits GitHub

Vue d’ensemble

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 À propos de 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 de migration est GitHub.com, décidez si vous voulez migrer organisation par organisation ou référentiel par référentiel.

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'gh-repo-stats extension pour les données GitHub CLI. 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.

Après avoir utilisé l’analyseur, vous pouvez adapter vos données d’inventaire par rapport au planning souhaitée. Si votre organisation peut résister à un plus haut degré de changement, vous pouvez probablement migrer tous vos dépôts à la fois, en concentrant vos efforts de migration sur quelques jours. Toutefois, vous pouvez avoir plusieurs équipes qui ne peuvent pas migrer en même temps. Dans ce cas, vous souhaiterez probablement séquencer et échelonner vos migrations pour rentrer dans le planning des équipes, ce qui prolongera vos efforts de migration.

1. Utilisez l'gh-repo-statsextension pour les données GitHub CLI, puis passez en revue votre inventaire de migration.
2. Pour savoir quand les équipes peuvent être prêtes à migrer, interrogez les parties prenantes.
3. Passez en revue le reste de ce guide, puis décidez d’un planning de migration.

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 « Informations sur les migrations entre les produits GitHub ».
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 « Gestion de l’accès pour une migration entre des produits GitHub ».
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 une migration entre des produits GitHub.

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 Gestion de l’accès pour une migration entre des produits GitHub.

   Remarque

   N’oubliez pas d’attribuer le rôle de migrateur à la fois à l’organisation source et à l’organisation de destination.

4. 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 une migration entre des produits GitHub.

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.

Quel est notre plan pour les noms d’entreprise et d’organisation ?

Si vous effectuez une migration entre des comptes sur GitHub.com, gardez à l’esprit qu’il existe des contraintes de nommage pour les comptes d’utilisateur, d’organisation et d’entreprise. Si vous devez réutiliser le nom d’une organisation ou d’une entreprise pour la migration, nous vous recommandons de renommer les comptes avant de les supprimer. Le renommage rend le nom d’un compte d’utilisateur, d’organisation ou d’entreprise immédiatement disponible pour une réutilisation.

Les comptes d’organisation sur GitHub Enterprise partagent le même espace de noms ; deux comptes d’utilisateur/d’organisation ne peuvent pas avoir le même nom. Les comptes d’entreprise sur GitHub Enterprise partagent le même espace de noms ; deux comptes d’entreprise ne peuvent pas avoir le même nom.

Exécution de vos migrations

Pour vous aider à identifier les problèmes qui peuvent être propres à votre entreprise, nous vous recommandons vivement d’effectuer un essai de votre migration. Avec un essai, vous apprendrez :

• Indique si la migration d’un référentiel donné peut se terminer correctement.
• Indique si vous pouvez récupérer le référentiel migré vers un état utilisable.
• Combien de temps une migration prendra-t-elle pour s'exécuter.

Les exécutions d’essai peuvent se produire à tout moment et le travail n’a pas besoin d’arrêter pendant la migration. 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 une migration entre des produits GitHub ».
3. Exécutez les migrations d’essai.
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.
7. 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 une migration entre des produits GitHub.
8. Si vous exécutez une migration de référentiel et que vous souhaitez migrer les paramètres pour les produits GitHub Advanced Security, activez les produits 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 ».
9. Exécutez vos migrations de production. Pour plus d’informations, consultez À propos de GitHub Enterprise Importer ou Migration d’organisations de GitHub.com vers GitHub Enterprise Cloud.
10. Si vous le souhaitez, supprimez l’organisation de test.

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.

• Vérification de l'état de la migration
• 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 des fonctionnalités de GitHub Advanced Security
• Activation des webhooks
• Réinstallation des GitHub Apps
• Recréation des équipes
• Récupération des mannequins

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.

• Si vous avez exécuté la migration à l'aide de l'API GraphQL, vous pouvez interroger les champs state et failureReason sur l'objet RepositoryMigration.

Si la migration a échoué, le journal de migration peut contenir des informations supplémentaires sur la cause de l'échec. Pour plus d'informations, consultez Examen du journal de migration.

Examen du journal de migration

Examinez le journal de migration pour chaque référentiel migré. Pour plus d’informations, consultez « Accès à vos journaux de migration pour GitHub Enterprise Importer ».

Si la migration a échoué, le journal peut contenir des informations supplémentaires sur la cause de l'échec.

Si la migration a réussi, il peut y avoir des avertissements dans le journal de migration représentant des éléments de données spécifiques (par exemple des demandes de tirage (pull requests), des problèmes ou des commentaires) qui n'ont pas été migrés ou qui ont été migrés avec des avertissements.

Pour plus d'informations sur la compréhension des avertissements de migration, consultez Résolution des problèmes de votre migration avec GitHub Enterprise Importer. Après avoir examiné les avertissements de migration, vous devrez décider si vous pouvez les accepter et poursuivre votre action.

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 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 changer la visibilité d’un dépôt à partir de la ligne de commande. 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écuteur plus grand, exécuteurs d’auto-hébergement 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. Si vous utilisez des exécuteur plus grand, reconfigurez vos exécuteurs.

   • Configurez des groupes d’exécuteurs pour contrôler l'accès à vos exécuteurs. Pour plus d’informations, consultez « Contrôle de l’accès aux exécuteurs plus grands ».
   • Configurer vos exécuteur plus grand. Pour plus d’informations, consultez « Gestion des exécuteurs de plus grande taille ».
   • Mettez à jour vos flux de travail pour pointer vers vos exécuteurs. Pour plus d’informations, consultez « Exécution de travaux sur des exécuteurs de plus grande taille ».

3. Rajoutez tous les secrets chiffrés.

   • Pour utiliser le navigateur, consultez Utilisation de secrets dans GitHub Actions.
   • Pour utiliser GitHub CLI, consultez gh secret dans la documentation GitHub CLI.

4. Reconfigurez les environnements. Pour plus d’informations, consultez « Gestion des 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 une migration entre des produits GitHub ».

Gestion des fonctionnalités de GitHub Advanced Security

Si vous avez activé les produits GitHub Advanced Security pour l’organisation de destination avant la migration des référentiels, 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 « Points de terminaison d’API REST pour l’analyse de secrets ».

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 « Points de terminaison d’API REST pour l’analyse de codes ».

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

Reconfiguration des fonctionnalités pour différente

Si vous avez migré de GitHub.com vers GitHub Enterprise Cloud avec résidence des données, certaines fonctionnalités fonctionnent différemment et d'autres nécessitent une configuration différente ou supplémentaire. Consultez Vue d’ensemble des fonctionnalités de GitHub Enterprise Cloud avec résidence des données.

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 « Installation de votre propre application GitHub ».

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 gérer les utilisateurs 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éer une équipe d’organisation ».
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 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.

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. 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 mannequins pour GitHub Enterprise Importer.
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 ».