Migration à partir de Bitbucket Server avec GitHub Enterprise Importer

À propos des migrations à partir de Bitbucket Server

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 de Bitbucket Server, vous pouvez utiliser ce guide pour planifier et implémenter votre migration, puis effectuer des tâches de suivi.

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.

• Nombre de référentiels
• 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.

Une fois que vous avez effectué l’inventaire des dépôts que vous devez migrer, vous pouvez adapter vos données d’inventaire par rapport au planning souhaité. 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. Déterminez le nombre de dépôts et de demandes de tirage que vous devez migrer.
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.

Pour les migrations à partir de Bitbucket Server, GitHub Enterprise Importer migre uniquement les dépôts Git et les demandes de tirage. Toutes les autres ressources, telles que les pipelines CI, restent dans Bitbucket Server.

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

1. Passez en revue les données migrées à partir de Bitbucket Server. 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 dans GitHub, ou un propriétaire d’organisation doit vous accorder le rôle de migrateur.

Vous devez également disposer des autorisations requises et de l’accès à votre instance Bitbucket Server :

• Autorisations d’administrateur ou de super administrateur
• Si votre instance Bitbucket Server exécute Linux, utilisez l’accès SFTP à l’instance, en utilisant une clé privée SSH prise en charge (voir « Gestion de l’accès pour GitHub Enterprise Importer »)
• Si votre instance Bitbucket Server exécute Windows, le partage de fichiers (SMB) accède à l’instance

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 ».
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 GitHub Enterprise Importer ».
5. Confirmez que le migrateur dispose d’autorisations d’administrateur ou de super administrateur et d’un accès SFTP pour votre instance Bitbucket Server.

Quelle structure organisationnelle voulons-nous dans GitHub ?

Ensuite, planifiez la structure organisationnelle que vous allez créer dans GitHub.

Dans Bitbucket Server, les dépôts sont regroupés dans des projets. Dans GitHub, les dépôts appartiennent aux organisations. Toutefois, vous ne devez pas supposer que la meilleure approche consiste à créer une organisation dans GitHub par projet dans Bitbucket Server.

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 dépôt migré appartient à l’une de ces organisations, ce qui 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 sur GitHub. Pour plus d’informations, consultez « À propos des équipes ».

Si vous souhaitez répartir votre effort de migration, envisagez de procéder par organisation.

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.
6. 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. Exécutez vos migrations de production. Pour plus d’informations, consultez « Migration de dépôts de Bitbucket Server vers GitHub Enterprise Cloud ».
8. 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.

• 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 Bitbucket Server, GitHub Enterprise Importer ne tente pas de migrer les autorisations de dépôt à partir de Bitbucket Server.

Pour accorder l’accès aux dépôts migrés, vous pouvez créer des équipes et accorder à chaque équipe l’accès au dépôt.

1. Créez des é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 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 ».