Migration de votre référentiel avec Enterprise Live Migrations

Prerequisites

Assurez-vous que vous êtes prêt pour votre migration. Consultez « Préparation de votre migration dynamique de GitHub Enterprise Server vers GHE.com ».

1. Créer des jetons d’accès

Vous devez vous authentifier avec un personal access token (classic) pour la source et la destination de la migration. Pour obtenir des instructions détaillées, consultez Gestion de vos jetons d’accès personnels.

          **Notez les deux jetons**, car vous en aurez besoin à l’étape suivante.

1. Créez un personal access token (classic) sur GitHub Enterprise Server avec les périmètres suivants.

   • repo
   • admin:org
   • admin:repo_hook
   • admin:org_hook

2. Créez un personal access token (classic) sur GHE.com avec les étendues suivantes.

   • repo
   • workflow
   • admin:org
   • admin:repo_hook
   • admin:enterprise

3. Si l’authentification unique est appliquée à l’organisation GHE.com cible, autorisez le jeton GHE.com.

2. Configurer GitHub Enterprise Server

Vous devez définir une configuration sur l’instance avant d’effectuer GitHub Enterprise Server une migration. Ces valeurs de configuration s’appliquent à toutes les ELM migrations. Les développeurs sur GitHub Enterprise Server pourraient connaître un court temps d'arrêt lorsque vous appliquez la nouvelle configuration.

1. Accédez à l’interpréteur de commandes d’administration GitHub Enterprise Server via SSH. Consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».

2. Définissez les variables de configuration suivantes avec ghe-config.

   Par exemple : ghe-config app.elm-exporter.enabled true

   Variable	Définissez cette valeur sur...
   app.elm-exporter.enabled	true
   app.elm.internal-webhooks-enabled	true
   app.elm-exporter.webhooks-loopback-address-enabled	true
   secrets.elm-exporter.migration-target-url	URL de l’API pour votre entreprise de destination (par exemple : https://api.octocorp.ghe.com). N’incluez pas de barre oblique finale dans l’URL.
   secrets.elm-exporter.migration-target-token	Jeton d’accès que vous avez créé pour GHE.com.
   secrets.elm-exporter.source-token	Jeton d’accès que vous avez créé pour GitHub Enterprise Server.
   secrets.elm-exporter.source-user	Nom d’utilisateur associé au GitHub Enterprise Server jeton (par exemple : ghe-admin).

3. Si vous n’avez pas encore activé les migrations ni configuré le stockage d’objets blob sur l’instance, vous pouvez les configurer maintenant. Vous pouvez vérifier vos paramètres existants dans la section « Migrations » de la console de gestion (HOSTNAME/setup/settings).

   Vous pouvez utiliser les valeurs par défaut suivantes, ce qui n’introduit aucune fonctionnalité inattendue.

   Shell

   ghe-config app.migrations.enabled true
   

   Shell

   ghe-config secrets.migrations.blob-storage-type local-storage
   

4. Appliquez la configuration.

   Shell

   ghe-config-apply
   

3. Définir les variables d’environnement requises

Lorsque la configuration a été appliquée et avant de démarrer une migration, définissez les variables d’environnement requises. Par exemple:

export API_URL='http://localhost:1738'

L’une de ces valeurs peut également être fournie en tant qu’indicateurs CLI sur n’importe quelle elm commande, qui prend la priorité sur les variables. Par exemple : --api-url http://localhost:1738.

4. Créer une migration

Créez une migration en spécifiant les détails du référentiel source et cible. --pat-name doit être défini comme valeur statique system-pat. Les autres valeurs sont des paramètres par défaut spécifiques à votre environnement.

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

Par exemple:

elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo \
  --target-api $MIGRATION_TARGET_URL \
  --pat-name system-pat

Indicateurs facultatifs :

• --start: si vous êtes prêt à démarrer la migration immédiatement.
• --target-visibility: les référentiels migrés sont créés avec une visibilité interne par défaut, mais vous pouvez spécifier private.

Enregistrer l’ID de migration

Vous devez voir une réponse semblable à ce qui suit :

{
  "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9",
  "expiresAt": "2026-02-11T21:49:33.619162159Z"
}

Exportez la migrationId variable en tant que variable, car vous en aurez besoin pour les commandes suivantes. Par exemple:

export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'

5. Démarrer la migration

Si vous n’avez pas déjà démarré la migration, démarrez-la maintenant à l’aide de l’ID de migration que vous venez d’enregistrer.

elm migration start --migration-id $MIGRATION_ID

elm migration start --migration-id $MIGRATION_ID

Cela lance les processus de remplissage et de mise à jour dynamique. ELM collecte désormais des données à partir du référentiel source et surveille les événements webhook pris en charge.

6. Surveiller la migration

Une fois la migration démarrée, vous devez voir un nouveau référentiel sur GHE.com. Pendant la migration, vous verrez le dépôt remplir avec une charge initiale de données et recevoir des mises à jour lorsque les développeurs continuent à travailler dans le référentiel source.

Exécutez régulièrement la commande suivante pour surveiller l’état de la migration. Vous verrez une répartition des états de la source et de la cible, ainsi que des informations sur les données dynamiques migrées.

elm migration status --migration-id $MIGRATION_ID

elm migration status --migration-id $MIGRATION_ID

L’indicateur le plus important dans la réponse est l’état de l’objet combinedState . Lorsque l’état atteint COMBINED_STATUS_READY_FOR_CUTOVER, vous devez être prêt à passer à l’étape suivante. Toutefois, vous serez averti dans le displayMessage si des ressources individuelles n'ont pas pu migrer, que vous devrez peut-être examiner.

Par exemple:

  "combinedState":  {
    "status":  "COMBINED_STATUS_READY_FOR_CUTOVER",
    "displayMessage":  "Ready for cutover (1 resources failed)",
    "repositories":  [
      {
        "repositoryNwo":  "new-test-org/my-new-repo",
        "phase":  "REPOSITORY_PHASE_READY_FOR_CUTOVER",
        "displayStatus":  "Ready for cutover (1 failed)"
      }
    ],
    "readyForCutover":  true,
    "cutoverBlockers":  []
  },

Conseils :

• Si vous exécutez plusieurs migrations, vous pouvez vérifier l’état de toutes ces dernières elm migration list. Cette commande affiche les migrations en cours par défaut, mais vous pouvez également filtrer par --status.
• Si vous rencontrez des statuts d'erreur qui nécessitent une attention particulière, consultez Résolution des problèmes de migrations dynamiques de GitHub Enterprise Server vers GHE.com.

7. Terminer la migration

Quand une migration est prête pour la transition, vous pouvez effectuer la migration. Le processus de basculement verrouille le référentiel source, ce qui le rend définitivement indisponible pour les développeurs, sauf si un administrateur le déverrouille.

elm migration cutover-to-destination --migration-id $MIGRATION_ID

elm migration cutover-to-destination --migration-id $MIGRATION_ID

Continuez à surveiller la migration. Lorsque vous voyez l’état MIGRATION_STATUS_COMPLETED en haut de la réponse, la migration est terminée, bien qu’il existe des tâches de suivi permettant d’accorder l’accès aux utilisateurs à partir de GitHub Enterprise Server.

Étapes suivantes

Donnez aux utilisateurs l’accès au nouveau référentiel et rapprochez l’activité avec les comptes d’utilisateur. Consultez « Fin de votre migration dynamique de GitHub Enterprise Server vers GHE.com ».