# Migration de votre référentiel avec Enterprise Live Migrations Migrez de GitHub Enterprise Server vers GHE.com avec un temps d’arrêt minimal. > \[!NOTE] > Enterprise Live Migrations est préversion publique et sujet à changement. > \[!TIP] À mesure que vous suivez ce guide, vous pouvez vous référer à [Référence CLI pour les migrations en direct Enterprise](/fr/enterprise-server@3.18/migrations/elm/elm-cli-reference) pour obtenir des informations d’utilisation plus détaillées. Si vous rencontrez des erreurs, consultez [Résolution des problèmes de migrations dynamiques de GitHub Enterprise Server vers GHE.com](/fr/enterprise-server@3.18/migrations/elm/troubleshooting). ## 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](/fr/enterprise-server@3.18/migrations/elm/prepare-for-your-migration) ». ## 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](/fr/enterprise-server@3.18/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic). **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)](/fr/enterprise-server@3.18/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-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 copy ghe-config app.migrations.enabled true ``` ```shell copy ghe-config secrets.migrations.blob-storage-type local-storage ``` 4. Appliquez la configuration. ```shell copy 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: ```shell export API_URL='http://localhost:1738' ``` > \[!IMPORTANT] Copiez les valeurs pour `API_URL` et `MIGRATION_MANAGER_HMAC_KEY` mot à mot. Les autres variables sont spécifiques à votre environnement. | Variable | Valeur requise | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | API\_URL | `http://localhost:1738` | | MIGRATION\_MANAGER\_HMAC\_KEY | `$(ghe-config secrets.elm-exporter.elm-exporter-hmac-keys)` | | 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. | | MIGRATION\_TARGET\_TOKEN | Le personal access token (classic) pour GHE.com | 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. > \[!NOTE] Il `target-org` peut être nouveau ou existant. Si l’organisation cible n’existe pas déjà, elle est créée pendant la migration. Toutefois, aucun paramètre de l’organisation source n’est migré. ```shell copy 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: ```shell 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 : ```json { "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: ```shell 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. ```shell copy 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. ```shell copy 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: ```json "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](/fr/enterprise-server@3.18/migrations/elm/troubleshooting#statuses-and-recommended-actions). ## 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. ```shell copy 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](/fr/enterprise-server@3.18/migrations/elm/complete-your-migration) ».