# 使用企业实时迁移迁移存储库 在停机时间最短的情况下，从GitHub Enterprise Server迁移到GHE.com。 > \[!NOTE] > Enterprise Live Migrations 位于 公开预览，可能会有变动。 > \[!TIP] 按照本指南操作，可以参考 [企业实时迁移 命令行界面参考](/zh/enterprise-server@3.22/migrations/elm/elm-cli-reference) 获取更详细的用法信息。 如果遇到错误，请参阅 [排查从 GitHub Enterprise Server 到 GHE.com 的实时迁移问题](/zh/enterprise-server@3.22/migrations/elm/troubleshooting)。 ## 先决条件 请确保已准备好进行迁移。 请参阅“[准备从 GitHub Enterprise Server 到 GHE.com 的实时迁移](/zh/enterprise-server@3.22/migrations/elm/prepare-for-your-migration)”。 ## 1.创建访问令牌 必须对迁移的源和目标进行personal access token (classic)的身份验证。 有关详细说明，请参阅“[管理个人访问令牌](/zh/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic)”。 **记下这两个令牌**，因为下一步中将需要它们。 1. 在personal access token (classic)上创建GitHub Enterprise Server，使用以下作用域。 * `repo` * `admin:org` * `admin:repo_hook` * `admin:org_hook` 2. 在personal access token (classic)上创建GHE.com，使用以下作用域。 * `repo` * `workflow` * `admin:org` * `admin:repo_hook` * `admin:enterprise` 3. 如果在目标组织GHE.com上强制实施单一登录，请对GHE.com令牌进行授权。 ## 2. 配置 GitHub Enterprise Server 在执行迁移之前， GitHub Enterprise Server 必须在实例上设置一些配置。 这些配置值适用于所有 ELM 迁移。 GitHub Enterprise Server应用新配置时，开发人员可能会遇到短暂的停机时间。 1. GitHub Enterprise Server通过 SSH 访问管理程序。 请参阅“[访问管理 shell (SSH)](/zh/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)”。 2. 使用 `ghe-config`. 设置以下配置变量。 例如：`ghe-config app.elm-exporter.enabled true` | 可变 | 将此设置为... | | ---------------------------------------------------- | --------------------------------------------------- | | `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` | 目标企业的 API URL（例如： `https://api.octocorp.ghe.com`） 。 | **不要**在 URL 的末尾包含尾部斜杠。 | \| `secrets.elm-exporter.migration-target-token` | 为 GHE.com 创建的访问令牌。 | \| `secrets.elm-exporter.source-token` | 为 GitHub Enterprise Server 创建的访问令牌。 | \| `secrets.elm-exporter.source-user` | 与 GitHub Enterprise Server 令牌关联的用户名（例如： `ghe-admin`） 。 | \| `app.migrations.enabled` | 如果尚未在实例上启用迁移，则必须将此设置为 `true`。 | 1. 应用配置。 ```shell copy ghe-config-apply ``` ## 3.设置所需的环境变量 应用配置后，在开始迁移之前，请设置所需的环境变量。 例如： ```shell export API_URL='http://localhost:1738' ``` > \[!IMPORTANT] 复制 `API_URL` 和 `MIGRATION_MANAGER_HMAC_KEY` 的值，逐字复制。 其他变量特定于你的环境。 | 可变 | 所需的值 | | --------------------------------- | ----------------------------------------------------------- | | API\_URL | `http://localhost:1738` | | MIGRATION\_MANAGER\_HMAC\_KEY | `$（ghe-config secrets.elm-exporter.elm-exporter-hmac-keys）` | | MIGRATION\_TARGET\_URL | 目标企业的 API URL（例如： `https://api.octocorp.ghe.com`） 。 | | **不要**在 URL 的末尾包含尾部斜杠。 | | | 迁移目标标记 (MIGRATION\_TARGET\_TOKEN) | for personal access token (classic)GHE.com | 这些值中的任何值也可以作为 CLI 标志提供给任何 `elm` 命令，这将优先于变量。 例如： `--api-url http://localhost:1738`。 ## 4.创建迁移 通过指定源和目标存储库详细信息创建新的迁移。 `--pat-name` 必须设置为 `system-pat` 静态值。 其他值是特定于您环境的占位符。 > \[!NOTE] > `target-org`可以是新的或现有的。 如果目标组织尚不存在，则会在迁移期间创建它。 但是，不会迁移来自源组织的设置。 ```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 ``` 例如： ```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 ``` 可选标志： * `--start`：如果已准备好立即开始迁移。 * `--target-visibility`：默认情况下，迁移的存储库是使用 **内部** 可见性创建的，但可以指定 `private`。 ### 保存迁移 ID 应会看到如下所示的响应： ```json { "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9", "expiresAt": "2026-02-11T21:49:33.619162159Z" } ``` 导出 `migrationId` 为变量，因为下一个命令将需要它。 例如： ```shell export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9' ``` ## 5.开始迁移 如果尚未启动迁移，请使用刚刚保存的迁移 ID 立即启动它。 ```shell copy elm migration start --migration-id $MIGRATION_ID ``` 这会启动回填和实时更新过程。 ELM 正在从源存储库收集数据，并且监听支持的 Webhook 事件。 ## 6.监视迁移 迁移开始时，应会看到新的存储库。GHE.com 在迁移过程中，你将看到存储库填充了初始数据负载，并在开发人员继续在源存储库中工作时接收更新。 定期运行以下命令以监视迁移状态。 你将看到源和目标的状态明细，以及有关要迁移的实时数据的信息。 ```shell copy elm migration status --migration-id $MIGRATION_ID ``` 响应中最重要的指示器是 **combinedState** 对象中的状态。 当状态达到 `COMBINED_STATUS_READY_FOR_CUTOVER`时，应准备好继续执行下一步。 但是，如果任何单个资源未能成功迁移，您可能需要对此进行调查，届时`displayMessage`中会发出警报。 例如： ```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": [] }, ``` 提示： * 如果运行的是多个迁移，则可以检查 `elm migration list`所有这些迁移的状态。 此命令默认显示正在进行的迁移，但也可以按此 `--status`进行筛选。 * 如果遇到需要注意的失败状态，请参阅 [排查从 GitHub Enterprise Server 到 GHE.com 的实时迁移问题](/zh/enterprise-server@3.22/migrations/elm/troubleshooting#statuses-and-recommended-actions)。 ## 7. 完成迁移 当迁移准备好进行切换时，可以完成迁移。 切换过程将存档源存储库，使其**永久处于只读状态**，除非存储库管理员将其解除存档。 ```shell copy elm migration cutover-to-destination --migration-id $MIGRATION_ID ``` 继续监视迁移。 在响应顶部看到 `MIGRATION_STATUS_COMPLETED` 状态时，迁移已完成，但仍有一些后续任务需要执行，以便为 GitHub Enterprise Server 的用户提供访问权限。 ## 后续步骤 向用户授予对新存储库的访问权限，并将活动与用户帐户进行协调。 请参阅“[完成从 GitHub Enterprise Server 到 GHE.com 的实时迁移](/zh/enterprise-server@3.22/migrations/elm/complete-your-migration)”。