# Миграция данных на GitHub Enterprise Server

После создания архива миграции вы можете импортировать данные в целевой GitHub Enterprise Server экземпляр. Вы сможете просмотреть изменения для потенциальных конфликтов, прежде чем окончательно применить изменения к целевому экземпляру.

## Подготовка перенесенных данных

1. Используя команду [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) , скопируйте архив миграции, сгенерированный из исходного экземпляра или организации, на целевую GitHub Enterprise Server цель:

   ```shell
   scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
   ```

2. SSH в целевом GitHub Enterprise Server экземпляре. Дополнительные сведения см. в разделе [Доступ к административной оболочке (SSH)](/ru/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell
   ssh -p 122 admin@HOSTNAME
   ```

3. Убедитесь, что архив миграции имеет достаточные разрешения на чтение.

   ```shell
   chmod 644 /home/admin/MIGRATION-GUID.tar.gz
   ```

4. Используйте команду `ghe-migrator prepare`, чтобы подготовить архив для импорта в целевой экземпляр и создать новый уникальный идентификатор миграции, который будет использоваться в последующих шагах:

   ```shell
   ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
   ```

   * Чтобы начать новую попытку импорта, запустите `ghe-migrator prepare` еще раз и получите новый уникальный идентификатор миграции.
   * Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с `--staging-path=/full/staging/path`. По умолчанию — `/data/user/tmp`.

## Создание списка конфликтов миграции

1. Используя команду `ghe-migrator conflicts` с уникальным идентификатором миграции, создайте файл *conflicts.csv*:

   ```shell
   ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
   ```

   * Если не сообщается о конфликтах, можно безопасно импортировать данные.

2. При наличии конфликтов с помощью команды [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) скопируйте *conflicts.csv* на локальный компьютер:

   ```shell
   scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
   ```

3. [Продолжайте устранять конфликты миграции или настраивать пользовательские](#resolving-migration-conflicts-or-setting-up-custom-mappings) сопоставления.

## Просмотр конфликтов миграции

1. Откройте [conflicts.csv](https://en.wikipedia.org/wiki/Comma-separated_values#Application_support) с помощью текстового редактора или *программного обеспечения для работы с электронными таблицами, совместимого с форматом CSV*.
2. Руководствуясь приведенными ниже примерами и справочными таблицами, просмотрите файл *conflicts.csv*, чтобы убедиться, что при импорте будут выполнены соответствующие действия.

Файл *conflicts.csv* содержит *карту миграции* конфликтов и рекомендуемые действия. Карта миграции содержит сведения о том, какие данные переносятся из источника и как данные будут применены к целевому объекту.

| `model_name`   | `source_url`                                           | `target_url`                                           | `recommended_action` |
| -------------- | ------------------------------------------------------ | ------------------------------------------------------ | -------------------- |
| `user`         | `https://example-gh.source/octocat`                    | `https://example-gh.target/octocat`                    | `map`                |
| `organization` | `https://example-gh.source/octo-org`                   | `https://example-gh.target/octo-org`                   | `map`                |
| `repository`   | `https://example-gh.source/octo-org/widgets`           | `https://example-gh.target/octo-org/widgets`           | `rename`             |
| `team`         | `https://example-gh.source/orgs/octo-org/teams/admins` | `https://example-gh.target/orgs/octo-org/teams/admins` | `merge`              |

Каждая строка в *conflicts.csv* предоставляет следующие сведения:

| Имя                  | Описание                                                                       |
| -------------------- | ------------------------------------------------------------------------------ |
| `model_name`         | Тип изменяемых данных.                                                         |
| `source_url`         | Исходный URL-адрес данных.                                                     |
| `target_url`         | Ожидаемый целевой URL-адрес данных.                                            |
| `recommended_action` | Предпочтительное действие, которое выполнит `ghe-migrator` при импорте данных. |

### Возможные сопоставления для каждого типа записи

Существует несколько различных действий сопоставления, которые `ghe-migrator` может выполнить при передаче данных:

| `action`        | Описание                                                                                                                                                                                                                                                                           | Применимые модели                      |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
| `import`        | (по умолчанию) Данные из источника импортируются в целевой объект.                                                                                                                                                                                                                 | Все типы записей                       |
| `map`           | Вместо создания новой модели на основе исходных данных используется существующая запись в целевом объекте. Полезно для импорта репозитория в существующую организацию или сопоставления удостоверений пользователей в целевом объекте с удостоверениями пользователей в источнике. | Пользователи, организации              |
| `rename`        | Данные из источника переименовываются, а затем копируются в целевой объект.                                                                                                                                                                                                        | Пользователи, организации, репозитории |
| `map_or_rename` | Если целевой объект существует, данные сопоставляются с ним. В противном случае импортированная модель переименовывается.                                                                                                                                                          | Пользователи                           |
| `merge`         | Данные из источника совмещаются с существующими данными в целевом объекте.                                                                                                                                                                                                         | Teams                                  |

**Мы настоятельно рекомендуем просмотреть файл *conflicts.csv* и использовать `ghe-migrator audit`, чтобы убедиться, что выполняются нужные действия.** Если все выглядит хорошо, можно продолжить.

## Устранение конфликтов миграции или настройка пользовательских сопоставлений

Если вы считаете, что `ghe-migrator` выполнит неправильное изменение, можно внести исправления, изменив данные в *conflicts.csv*. Вы можете внести изменения в любую из строк в *conflicts.csv*.

Например, предположим, что `octocat` пользователь из источника сопоставляется с `octocat` целевым объектом.

| `model_name` | `source_url`                        | `target_url`                        | `recommended_action` |
| ------------ | ----------------------------------- | ----------------------------------- | -------------------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/octocat` | `map`                |

Вы можете сопоставить пользователя с другим пользователем в целевом объекте. Предположим, вы знаете, что `octocat` на самом деле должен быть `monalisa` в целевом объекте. Столбец можно изменить `target_url` в *conflicts.csv* , чтобы ссылаться `monalisa`на .

| `model_name` | `source_url`                        | `target_url`                         | `recommended_action` |
| ------------ | ----------------------------------- | ------------------------------------ | -------------------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `map`                |

В качестве другого примера, если вы хотите переименовать репозиторий в целевой экземпляр, измените его `octo-org/widgets` на `octo-org/amazing-widgets` и на `target_url``octo-org/amazing-widgets`.`recommend_action``rename`

| `model_name` | `source_url`                                 | `target_url`                                         | `recommended_action` |
| ------------ | -------------------------------------------- | ---------------------------------------------------- | -------------------- |
| `repository` | `https://example-gh.source/octo-org/widgets` | `https://example-gh.target/octo-org/amazing-widgets` | `rename`             |

### Добавление пользовательских сопоставлений

Распространенный сценарий во время миграции заключается в том, что у имена перенесенных пользователей в целевом объекте будут отличаться от тех, что назначены им в источнике.

Имея список имен пользователей в источнике и список имен пользователей в целевом объекте, вы можете создать CSV-файл с пользовательскими сопоставлениями, а затем применить его, чтобы имена пользователей и их данные были правильно сопоставлены после миграции.

Вы можете быстро создать CSV-файл пользователей, которые переносятся. Он необходим для применения пользовательских сопоставлений с помощью команды `ghe-migrator audit`:

```shell
ghe-migrator audit -m user -g MIGRATION-GUID > users.csv
```

Теперь вы можете изменить этот CSV-файл и ввести новый URL-адрес для каждого пользователя, которого вы хотите сопоставить или переименовать, а затем обновить четвертый столбец, чтобы выполнить `map` или `rename`.

Например, чтобы переименовать пользователя `octocat` в `monalisa` в целевом объекте `https://example-gh.target` создайте строку со следующим содержимым:

| `model_name` | `source_url`                        | `target_url`                         | `state`  |
| ------------ | ----------------------------------- | ------------------------------------ | -------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `rename` |

Один и тот же процесс можно использовать для создания сопоставлений для каждой записи, поддерживающей пользовательские сопоставления. Дополнительные сведения см. в [таблице возможных сопоставлений записей](#possible-mappings-for-each-record-type).

### Применение измененных данных миграции

1. После внесения изменений используйте команду [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) для применения измененного файла *conflicts.csv* (или любого другого файла *.csv* сопоставлений в правильном формате) к целевому экземпляру:

   ```shell
   scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
   ```

2. Повторно сопоставите данные миграции с помощью команды `ghe-migrator map`, передав путь к измененным файлу *.csv* и уникальному идентификатору миграции:

   ```shell
   ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
   ```

3. Если команда `ghe-migrator map -i conflicts.csv -g MIGRATION-GUID` сообщит, что конфликты по-прежнему существуют, снова выполните процесс разрешения конфликтов миграции.

## Применение импортированных данных на GitHub Enterprise Server

1. SSH в целевом GitHub Enterprise Server экземпляре. Дополнительные сведения см. в разделе [Доступ к административной оболочке (SSH)](/ru/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell
   ssh -p 122 admin@HOSTNAME
   ```

2. С помощью команды `ghe-migrator import` запустите процесс импорта. Что вам понадобится:

   * GUID миграции. Для получения дополнительной информации см. [раздел «Подготовка мигрированных данных для импорта в GitHub Enterprise Server](#preparing-the-migrated-data).
   * Ты personal access token для аутентификации. Используемый вами файл personal access token предназначен только для аутентификации как администратора сайта и не требует специального объёма или разрешений. Дополнительные сведения см. в разделе [Управление личными маркерами доступа](/ru/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).

   ```shell
   $ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN

   > Starting GitHub::Migrator
   > Import 100% complete /
   ```

   * Чтобы указать, где следует выполнить подготовку файлов миграции, добавьте команду с `--staging-path=/full/staging/path`. По умолчанию — `/data/user/tmp`.

## Проверка данных миграции

По умолчанию `ghe-migrator audit` возвращает каждую запись. Кроме того, это позволяет фильтровать записи по следующим критериям:

* Типы записей.
* Состояние записей.

Типы записей соответствуют тем, которые находятся в [перенесенных данных](/ru/enterprise-server@3.22/migrations/using-ghe-migrator/about-ghe-migrator#migrated-data).

## Фильтры типов записей

| Тип записи                                                    | Имя фильтра                   |
| ------------------------------------------------------------- | ----------------------------- |
| Пользователи                                                  | `user`                        |
| Организации                                                   | `organization`                |
| Репозитории                                                   | `repository`                  |
| Teams                                                         | `team`                        |
| Milestones                                                    | `milestone`                   |
| Проблемы                                                      | `issue`                       |
| Комментарии к проблеме                                        | `issue_comment`               |
| Запросы на включение внесенных изменений                      | `pull_request`                |
| Проверки запросов на включение изменений                      | `pull_request_review`         |
| Комментарии к фиксации                                        | `commit_comment`              |
| Комментарии к проверке запроса на вытягивание                 | `pull_request_review_comment` |
| Выпуски                                                       | `release`                     |
| Действия, выполняемые для запросов на вытягивание или проблем | `issue_event`                 |
| Защищенные ветви                                              | `protected_branch`            |

## Фильтры состояния записи

| Состояние записи | Описание                          |
| ---------------- | --------------------------------- |
| `export`         | Запись будет экспортирована.      |
| `import`         | Запись будет импортирована.       |
| `map`            | Запись будет сопоставлена.        |
| `rename`         | Запись будет сопоставлена.        |
| `merge`          | Запись будет объединена.          |
| `exported`       | Запись экспортирована успешно.    |
| `imported`       | Запись импортирована успешно.     |
| `mapped`         | Запись сопоставлена успешно.      |
| `renamed`        | Запись переименована успешно.     |
| `merged`         | Запись объединена успешно.        |
| `failed_export`  | Не удалось экспортировать запись. |
| `failed_import`  | Не удалось импортировать запись.  |
| `failed_map`     | Не удалось сопоставить запись.    |
| `failed_rename`  | Не удалось переименовать запись.  |
| `failed_merge`   | Не удалось объединить запись.     |

## Фильтрация записей аудита

С помощью команды `ghe-migrator audit` можно отфильтровать данные по типу записи с помощью флага `-m`. Аналогичным образом можно отфильтровать состояние импорта с помощью флага `-s`. Эта команда выглядит следующим образом:

```shell
ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID
```

Например, чтобы просмотреть каждую успешно импортированную организацию и команду, необходимо ввести следующее:

```shell
$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed
```

**Настоятельно рекомендуется проводить аудит каждой операции импорта, завершившейся сбоем.** Для этого введите:

```shell
$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed
```

Если у вас есть опасения по поводу неудачного импорта, вы можете связаться с нами, посетив [Поддержка GitHub Enterprise](https://support.github.com).

## Завершение импорта на GitHub Enterprise Server

После применения миграции к целевому экземпляру и проверки миграции следует разблокировать репозитории и удалить их из источника. Перед удалением исходных данных рекомендуется подождать около двух недель, чтобы убедиться, что все работает должным образом.

## Разблокировка репозиториев на целевом экземпляре

1. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе [Доступ к административной оболочке (SSH)](/ru/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell copy
   ssh -p 122 admin@HOSTNAME
   ```
2. Разблокируйте все импортированные репозитории с помощью команды `ghe-migrator unlock`. Вам потребуется GUID миграции:

```shell
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
```

> \[!WARNING]
> Если в вашем репозитории есть GitHub Actions рабочие процессы, использующие триггер `schedule` , рабочие процессы не будут запускаться автоматически после импорта. Чтобы снова запустить запланированные рабочие процессы, отправьте фиксацию в репозиторий. Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).

## Разблокировка репозиториев в источнике

После завершения миграции необходимо разблокировать репозитории в источнике.

### Разблокировка репозиториев из организации на GitHub.com

Чтобы разблокировать репозитории организации GitHub.com , вы отправляете `DELETE` запрос на [конечную точку разблокировки миграции](/ru/rest/migrations#unlock-an-organization-repository). Что вам понадобится:

* Маркер доступа для проверки подлинности
* Уникальный `id` миграции
* Имя репозитория для разблокировки

```shell
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock
```

### Удаление репозиториев из организации на GitHub.com

После разблокировки репозиториев организации следует удалить все репозитории, которые GitHub.com вы ранее мигрировали через [эндпоинт удаления репозитория](/ru/enterprise-server@3.22/rest/repos/repos#delete-a-repository). Вам потребуется маркер доступа для проверки подлинности

```shell
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  https://api.github.com/repos/ORG-NAME/REPO_NAME
```

### Разблокировка репозиториев из экземпляра GitHub Enterprise Server

1. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе [Доступ к административной оболочке (SSH)](/ru/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell copy
   ssh -p 122 admin@HOSTNAME
   ```
2. Разблокируйте все импортированные репозитории с помощью команды `ghe-migrator unlock`. Вам потребуется GUID миграции:

```shell
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
```