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

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

> \[!NOTE]
> Enterprise Live Migrations находится в Публичный предварительный просмотр процессе и может измениться.

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

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

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

## 1. Создание токенов доступа

Вы должны аутентифицироваться с помощью a personal access token (classic) как для источника, так и для назначения миграции. Подробные инструкции см. в разделе [Управление личными маркерами доступа](/ru/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) ON **GitHub Enterprise Server** с помощью следующих телескопов.

   * `repo`
   * `admin:org`
   * `admin:repo_hook`
   * `admin:org_hook`

2. Создайте personal access token (classic) ON **GHE.com** с помощью следующих телескопов.

   * `repo`
   * `workflow`
   * `admin:org`
   * `admin:repo_hook`
   * `admin:enterprise`

3. Если для целевой организации GHE.comGHE.com на , авторизуйте токен.

## 2. Настройте GitHub Enterprise Server

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

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

   | 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.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` дословно. Остальные переменные специфичны для вашей среды.

| Variable                            | Обязательное значение                                                               |
| ----------------------------------- | ----------------------------------------------------------------------------------- |
| API\_URL                            | `http://localhost:1738`                                                             |
| MIGRATION\_MANAGER\_HMAC\_KEY       | `$(ghe-config secrets.elm-exporter.elm-exporter-hmac-keys)`                         |
| MIGRATION\_TARGET\_URL              | URL API для вашего целевого предприятия (например: `https://api.octocorp.ghe.com`). |
| **Не** указывайте слэш в конце URL. |                                                                                     |
| MIGRATION\_TARGET\_TOKEN            | Фор 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](/ru/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.

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

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