# Миграция вашего репозитория с помощью Enterprise Live Migrations

Переходите с GitHub Enterprise Server В GHE.com с минимальным простоем.

> \[!TIP] Следуя этому руководству, вы можете ознакомиться с [Справочник CLI Enterprise Live Migrations](/ru/enterprise-server@3.20/migrations/elm/elm-cli-reference) для получения более подробной информации об использовании. Если вы столкнётесь с ошибками, смотрите [Устранение неполадок при миграции в реальном времени с GitHub Enterprise Server на GHE.com](/ru/enterprise-server@3.20/migrations/elm/troubleshooting).

## Необходимые условия

Убедитесь, что среды и разработчики готовы к миграции. См [. раздел AUTOTITLE](/ru/enterprise-server@3.20/migrations/elm/prepare-for-your-migration).

## 1. Настройка GitHub Enterprise Server

Перед созданием маркеров и выполнением миграции необходимо задать определенную конфигурацию для GitHub Enterprise Server экземпляра. Эти значения конфигурации применимы ко всем ELM миграциям. Разработчики GitHub Enterprise Server могут столкнуться с коротким простоем при применении новой конфигурации.

1. Доступ к GitHub Enterprise Server административной оболочке через SSH. См [. раздел AUTOTITLE](/ru/enterprise-server@3.20/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`

   | Variable                                             | Настрой это на...                                                                   |
   | ---------------------------------------------------- | ----------------------------------------------------------------------------------- |
   | `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 API для вашего целевого предприятия (например: `https://api.octocorp.ghe.com`). |

**Не** указывайте слэш в конце URL. |
\| `secrets.elm-exporter.source-user` | Имя пользователя, связанное с маркером оператора GitHub Enterprise Server . Это должно быть ваше имя пользователя GitHub Enterprise Server; если кто-то другой собирается создать этот токен, значение здесь должно быть задано в качестве имени пользователя. Мы рекомендуем `ghe-admin` пользователю. |

1. Примените конфигурацию.

   ```shell copy
   ghe-config-apply
   ```

2. Оставьте сеанс SSH. Остальные команды будут выполняться в локальном сеансе терминала.

## 2. Создание маркеров оператора с корпоративным доступом

Оператор должен пройти проверку подлинности как в исходном, так и в целевом personal access token (classic)предприятии. Инструкции по созданию маркеров см. в разделе [Управление личными маркерами доступа](/ru/enterprise-server@3.20/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).

**Убедитесь, что вы заметите оба маркера**, так как они потребуются на следующем шаге.

1. В **GitHub Enterprise Server** поле "Создать personal access token (classic) " и выбрать требуемую область:

   * `admin:enterprise`

   Этот маркер будет использоваться в качестве **исходного маркера** при настройке ELM CLI.

2. В **GHE.com** поле "Создать personal access token (classic) " и выбрать необходимые области:

   * `admin:enterprise`
   * `admin:org`

   Этот маркер будет использоваться в качестве **целевого маркера** при настройке ELM CLI.

## 3. Настройка средства командной ELM строки

Вы будете запускать миграцию из локального сеанса GitHub CLIтерминала, используя расширение .

1. Установите на локальном [GitHub CLI](https://cli.github.com/) компьютере. Необходимо использовать версию 2.0 или более позднюю.

2. Установите расширение ELM.

   ```shell copy
   gh extension install github/gh-elm
   ```

3. Запустите мастер установки, чтобы настроить расширение.

   ```shell copy
   gh elm configure
   ```

4. Следуйте инструкциям мастера установки, указав URL-адреса API (например, `https://api.SUBDOMAIN.ghe.com`для источника и назначения) и маркеры, созданные на предыдущем шаге.

Любое из этих значений также можно указать как флаги CLI для любой `gh elm` команды, которая будет иметь приоритет над конфигурацией. Например: `--target-url https://api.SUBDOMAIN.ghe.com`.

Этот процесс установки будет хранить URL-адреса в файле конфигурации для конкретной платформы в каталоге конфигурации операционной системы.`gh-elm/config.json` Маркеры доступа будут безопасно храниться в хранилище секретов компьютера.

## 4. Настройка секретов динамической миграции

Помимо маркеров оператора с корпоративным доступом, необходимо создать personal access token (classic) для исходных и целевых организаций. Эти действия необходимо повторить для каждой организации, из которых выполняется миграция.

### Создание маркеров доступа

ELM должен пройти проверку подлинности как personal access token (classic) для источника, так и для назначения миграции. Инструкции по созданию маркеров см. в разделе [Управление личными маркерами доступа](/ru/enterprise-server@3.20/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`

   Это целевой маркер.

   > \[!IMPORTANT]
   > Если единый вход применяется в целевой организации GHE.com, необходимо авторизовать GHE.com токен для единого входа.

### Настройка секретов организации ELM

Используйте команды, чтобы задать исходные и целевые `gh elm config` маркеры доступа:

1. Задайте исходный маркер.

   ```shell copy
   gh elm config set-source-pat EXISTING-GHES-ORG
   ```

   Вставьте исходный маркер в терминал при появлении запроса.

2. Задайте целевой маркер.

   ```shell copy
   gh elm config set-target-pat EXISTING-GHES-ORG
   ```

   При появлении запроса вставьте целевой маркер в терминал.

Вы также можете задать маркеры в интерактивном режиме, с помощью `gh elm config org-tokens EXISTING-GHES-ORG`или в параметрах `https://GHES_HOSTNAME/organizations/EXISTING-GHES-ORG/settings/secrets/elm-exporter/`организации.

## 5. Создание миграции

Создайте новую миграцию, указав данные исходного и целевой репозиторий.

> \[!NOTE] Они `target-org` могут быть новыми или уже существующими. Если целевая организация ещё не существует, она будет создана во время миграции. Однако настройки из исходной организации не будут мигрированы.

```shell copy
gh elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO
```

Рассмотрим пример.

```shell
gh elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo
```

Опциональные флаги:

* `--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'
```

## 6. Запуск миграции

Если вы ещё не начали миграцию, начните сейчас, используя только что сохранённый ID миграции.

```shell copy
gh elm migration start --migration-id $MIGRATION_ID
```

Это запускает процессы заполнения и обновления в реальном времени.
ELM Сейчас собирает данные из исходного репозитория и прослушивает поддерживаемые события Webhook.

## 7. Мониторинг миграции

Когда миграция начнётся, вы должны увидеть новый репозиторий на GHE.com. Во время миграции репозиторий заполняется первоначальной загрузкой данных и будет получать обновления по мере того, как разработчики продолжают работать в исходном репозитории.

Ход выполнения миграции можно отслеживать в интерактивном режиме `watch` с помощью команды:

```shell
gh elm migration watch $MIGRATION_ID
```

Это опрашивает API состояния миграции и отображает самообновляющий текстовый пользовательский интерфейс, который отражает текущий ход выполнения.

### Программный мониторинг с помощью `migration status`

Если требуется состояние миграции, подходящее для автоматизации, используйте `status` команду:

```shell copy
gh 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":  []
  },
```

Советы

* Если вы запускаете несколько миграций, вы можете проверить статус всех с помощью `gh elm migration list`. Эта команда по умолчанию показывает миграции в процессе, но вы также можете фильтровать по `--status`.
* Если вы столкнулись с статусами неудач, требующим внимания, смотрите [Устранение неполадок при миграции в реальном времени с GitHub Enterprise Server на GHE.com](/ru/enterprise-server@3.20/migrations/elm/troubleshooting#statuses-and-recommended-actions).

## 8. Завершение миграции

Когда миграция готова к переходу, вы сможете завершить её. Процесс перехода архивирует исходный репозиторий, делая **его постоянно доступным только для чтения** , если администратор репозитория не удалит его.

```shell copy
gh elm migration cutover --migration-id $MIGRATION_ID
```

Продолжайте отслеживать миграцию. Когда вы видите `MIGRATION_STATUS_COMPLETED` статус в верхней части ответа, миграция завершена, хотя есть некоторые последующие задачи, предоставляющие пользователям доступ из GitHub Enterprise Server.

## Дальнейшие действия

Дайте пользователям доступ к новому репозиторию и сверьте активность с учётными записями пользователей. См [. раздел AUTOTITLE](/ru/enterprise-server@3.20/migrations/elm/complete-your-migration).