Planifier votre migration de GitLab vers GitHub

Planifiez votre migration en comprenant votre chronologie, les données qui seront migrées et votre structure organisationnelle.

Run your migration

Article 2 de 7
Suivant:Gérer l’accès à une migration de GitLab vers GitHub

Dans cet article

Déterminez combien de données vous devez migrer

Déterminez d’abord votre chronologie, car elle forme 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 (projets)
  • Nombre de demandes de fusion

Remarque

Le minutage de la migration est largement basé sur le nombre de demandes de fusion dans un référentiel. Si vous souhaitez migrer 1 000 référentiels et que chaque référentiel a 100 demandes de fusion en moyenne, votre migration sera probablement très rapide. Si vous souhaitez migrer uniquement 100 référentiels, mais que les référentiels ont chacun 75 000 demandes de fusion en moyenne, la migration prend beaucoup plus de temps et nécessite plus de planification et de test.

Nous vous recommandons la commande inventory-report dans le GL2GH extension of the GitHub CLI. Cette commande se connecte à l’API GitLab et crée deux fichiers CSV. groups.csv répertorie vos groupes GitLab et projects.csv répertorie vos projets, y compris le nombre de demandes de fusion.

Pour produire les fichiers CSV, utilisez la commande suivante, en remplaçant GITLAB_SERVER_URL par l’URL de votre serveur GitLab (par exemple https://gitlab.com) et YOUR_GITLAB_GROUP par le groupe sur lequel vous souhaitez créer un rapport. Pour signaler tous les projets auquel vous pouvez accéder, omettez --gitlab-group. Pour toutes les options disponibles, exécutez gh gl2gh inventory-report --help.

Shell
gh gl2gh inventory-report --gitlab-server-url GITLAB_SERVER_URL --gitlab-group YOUR_GITLAB_GROUP

Après avoir effectué l’inventaire des référentiels que vous devez migrer, pesez vos données d’inventaire par rapport à votre chronologie 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.
  • Si vous avez des équipes qui ne sont pas en mesure de migrer en même temps, vous souhaiterez peut-être effectuer un traitement par lots et décaler vos migrations pour s’adapter aux chronologies des équipes, ce qui étend votre effort de migration.

Déterminer la GitHub structure organisationnelle

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

  • GitLab : groupes > instances > sous-groupes (qui peuvent être imbriqués jusqu’à 20 niveaux de profondeur) > projets (référentiels)
  • GitHub: référentiels de > d’organisation d’entreprise >

Après la migration vers GitHub, vous ne devez avoir qu’un seul compte d’entreprise et un certain nombre d’organisations appartenant à cette entreprise. Chaque groupe de niveau supérieur de GitLab correspond généralement à une seule organisation sur GitHub. Pour obtenir des conseils sur le nombre d’organisations à créer, consultez Meilleures pratiques pour organiser le travail dans votre entreprise.

Remarque

GitHub n’a pas d’équivalent des sous-groupes imbriqués de GitLab. Nous vous déconseillons de créer une organisation sur GitHub chaque sous-groupe, car cela peut entraîner une grande liste de dépôts non groupés au sein de chaque organisation. Au lieu de cela, vous pouvez gérer l’accès aux groupes de référentiels en créant des équipes.

Si vous souhaitez interrompre votre effort de migration en lots, la nouvelle structure peut vous aider à les déterminer. Si vous avez plusieurs groupes dans GitLab et que les dépôts de chaque groupe sont raisonnablement dimensionnés, envisagez le traitement par lot par groupe.

  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.

Configuration des autorisations de référentiel

Étant donné que les autorisations fonctionnent différemment dans GitHub GitLab, GitHub Enterprise Importer ne migre pas les autorisations de référentiel, les paramètres de groupe ou l’appartenance au groupe à partir de GitLab.

Dans GitLab, les membres reçoivent des rôles (tels que Invité, Reporter, Développeur, Maintenance ou Propriétaire) au niveau du groupe, du sous-groupe ou du projet, et ces rôles sont hérités dans la hiérarchie. Ces rôles ne sont pas mappés directement à GitHub. Vous devez donc recréer l’accès après la migration.

Pour donner aux utilisateurs l’accès aux dépôts migrés sur GitHub, nous vous recommandons de créer des équipes et d’accorder à chaque équipe le niveau d’accès approprié aux organisations et référentiels appropriés. Vous pouvez ensuite ajouter des personnes à ces équipes. Consultez « Équipes dans une entreprise ».