Миграция между продуктами GitHub с помощью GitHub Enterprise Importer

Сведения о миграциях между продуктами GitHub

С помощью GitHub Enterprise Importer можно выполнить миграцию в GitHub Enterprise Cloud. Дополнительные сведения см. в разделе Сведения о GitHub Enterprise Importer.

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

Планирование миграции

Чтобы спланировать миграцию, задайте себе следующие вопросы.

• Мы хотим выполнить миграцию по организации или репозиторию?
• Как скоро необходимо завершить миграцию?
• Мы понимаем, что будет перенесено?
• Кто будет выполнять миграцию?
• Хотим ли мы сохранить аналогичную структуру организации после миграции?

Мы хотим выполнить миграцию по организации или репозиторию?

Во-первых, если источником и назначением миграции являются GitHub.com, решите, нужно ли выполнять миграцию на основе организации или репозитория по репозиторию.

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

Однако при переносе организации все репозитории, принадлежащие исходной организации, переносятся одновременно. Вы не можете разбить репозитории на пакеты или пропустить миграцию каких-либо репозиториев организации. Если у вас есть большое количество репозиториев или вы не можете терпеть простои для всех репозиториев одновременно, вам может потребоваться выполнить миграцию репозитория.

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

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

Как скоро необходимо завершить миграцию?

• Число репозиториев
• Количество запросов на вытягивание
• Количество проблем
• Количество пользователей
• Использование проектов и вики-сайтов

Время миграции в значительной степени зависит от количества запросов на вытягивание и проблем в репозитории. Если вы хотите перенести 1000 репозиториев и в каждом репозитории в среднем есть 100 запросов на вытягивание и проблем, а в репозитории участвовали только 50 пользователей, миграция, скорее всего, будет очень быстрой. Если вы хотите перенести только 100 репозиториев, но каждый из них имеет в среднем 75 000 запросов на вытягивание и проблем и 5000 пользователей, миграция займет больше времени и потребует гораздо больше планирования и тестирования.

Мы понимаем, что будет перенесено?

Убедитесь, что вы и ваши заинтересованные лица понимаете, какие данные могут быть перенесены GitHub Enterprise Importer.

1. Просмотрите данные, перенесенные для источника миграции. Дополнительные сведения см. в разделе Поддержка миграции для GitHub Enterprise Importer.
2. Создайте список всех данных, которые потребуется вручную перенести или повторно создать.

Кто будет выполнять миграцию?

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

Решение о том, кто будет выполнять миграцию организации

Чтобы перенести организацию, вы должны быть владелец организации для исходной организации или владелец организации должна предоставить вам роль миграции для этой организации.

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

1. Убедитесь, что пользователь, который будет выполнять миграции, является корпоративным владельцем целевой корпоративной учетной записи.
2. Если этот пользователь не является владелец организации для исходной организации, предоставьте ему роль миграции для организации. Дополнительные сведения см. в разделе Granting the migrator role for GitHub Enterprise Importer.
3. Убедитесь, что пользователь правильно настроил personal access tokens для удовлетворения всех требований к доступу. Дополнительные сведения см. в разделе Управление доступом для GitHub Enterprise Importer.

Решение о том, кто будет выполнять миграцию репозитория

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

1. Решите, нужно ли выполнить миграцию с помощью владелец организации или предоставить роль миграции другому пользователю.

2. Если вы решили предоставить роль миграции, определите, какому человеку или команде вы предоставите эту роль.

3. Предоставьте роль миграции пользователю или команде. Дополнительные сведения см. в разделе Granting the migrator role for GitHub Enterprise Importer.

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

   1. Убедитесь, что пользователь правильно настроил personal access tokens для удовлетворения всех требований к доступу. Дополнительные сведения см. в разделе [AUTOTITLE](/migrations/using-github-enterprise-importer/preparing-to-migrate-with-github-enterprise-importer/managing-access-for-github-enterprise-importer).

Хотим ли мы сохранить аналогичную структуру организации после миграции?

Затем подумайте, хотите ли вы сохранить аналогичную структурную структуру организации после миграции. Если вы хотите разбить усилия по миграции на пакеты, это поможет определить пакеты. Если вы планируете поддерживать переписку "один к одному" между организациями в источнике и назначении, рекомендуется выполнять пакетную миграцию по организации. Это самый простой подход, особенно при миграции из GitHub.com, так как вы можете перенести всю организацию с помощью одной команды. При миграции из другого источника GitHub CLI может создать скрипт для переноса всех репозиториев в одной организации.

Если вы планируете изменить организационную структуру, рассмотрите другие факторы пакетной обработки. Вы можете пакетные репозитории, принадлежащие аналогичным командам или бизнес-подразделениям, а также пакетные пакеты в целевой организации. По возможности рекомендуется выполнять пакетную обработку по командам. Если вы выполняете пакетную обработку по подразделениям или целевым организациям, вы увеличите число заинтересованных лиц, что может привести к более коротким периодам времени для миграции.

Даже если вы измените организационную структуру, вы все равно можете подготовить сценарий для миграции. Используйте команду GitHub CLI, а затем при необходимости переместите строки для каждого репозитория в разные скрипты.

1. Определите структурную структуру вашей новой организации.
2. Решите, нужно ли разделить усилия по миграции на небольшие пакеты.
3. Если да, решите, как вы хотите разбить свои миграции.

Выполнение миграций

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

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

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

Пробные запуски не требуют много времени на координацию. GitHub Enterprise Importer никогда не требует простоя для пользователей переносимого репозитория. Однако мы рекомендуем остановить работу во время миграции в рабочей среде, чтобы гарантировать, что во время миграции не будут созданы новые данные, которые затем будут отсутствовать в перенесенном репозитории. Это не является проблемой для пробной миграции, поэтому пробные запуски могут выполняться в любое время. Чтобы сократить время, необходимое для завершения миграции пробной версии, можно запланировать пакеты для пробных запусков. Затем пользователи этих репозиториев могут самостоятельно проверять результаты.

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

1. Если вы выполняете миграцию репозитория, создайте тестовую организацию для пробных миграций.
2. Если ваша исходная организация использует списки разрешенных IP-адресов, настройте список так, чтобы разрешить доступ GitHub Enterprise Importer. Дополнительные сведения см. в разделе Управление доступом для GitHub Enterprise Importer.
3. Run the trial migrations. For more information, see "Подготовка к выполнению миграции с помощью GitHub Enterprise Importer."
4. Complete the follow-up tasks described below for the trial migrations.
5. Ask users to validate the results of the migrations.
6. Resolve any issues uncovered by your trial migrations. 1. If your destination uses IP allow lists, configure the list to allow access by GitHub Enterprise Importer. For more information, see "Управление доступом для GitHub Enterprise Importer."
7. Если вы выполняете миграцию репозитория и хотите перенести параметры GitHub Advanced Security, включите GitHub Advanced Security для целевой организации. Дополнительные сведения см. в разделе Управление параметрами безопасности и анализа для организации.
8. Выполните миграцию в рабочей среде. Дополнительные сведения см. в разделе Migrating repositories with GitHub Enterprise Importer или Миграция организаций с помощью GitHub Enterprise Importer.
9. При необходимости удалите тестовую организацию.

Выполнение последующих задач

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

• Просмотр журнала миграции
• Перенос объектов Git LFS
• Настройка видимости репозитория
• Настройка GitHub Actions
• Настройка списков разрешенных IP-адресов
• Управление функцией «GitHub Advanced Security»
• Включение веб-перехватчиков
• Переустановка GitHub Apps
• Воссоздание команд
• Восстановление манекенов

Просмотр журнала миграции

Сначала просмотрите журнал миграции для каждого перенесенного репозитория. Дополнительные сведения см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.

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

1. Просмотрите журналы миграции.
2. Просмотрите все предупреждения в каждом журнале и убедитесь, что ни один из них не блокирует принятие миграции. Дополнительные сведения см. в разделе Устранение неполадок миграции с помощью GitHub Enterprise Importer.

Перенос объектов Git LFS

GitHub Enterprise Importer не переносит объекты Git LFS. Если исходный репозиторий использует Git LFS, можно вручную отправить объекты Git LFS в перенесенный репозиторий локально. Дополнительные сведения см. в разделе Дублирование репозиториев.

Настройка видимости репозитория

All repositories are migrated as private, and only the user that ran the migration and organization owners will have access to the repository. If you don't want the repository to be private, change the visibility.

• You can change a repository's visibility in the browser. For more information, see "Настройка видимости репозитория."
• Alternatively, you can use GitHub CLI to change repository visibility from the command line. You can even add this command to the script that was generated to run your migrations. For more information, see gh repo edit in the GitHub CLI documentation.

Настройка GitHub Actions

Если вы используете GitHub Actions в репозитории, рабочие процессы автоматически переносятся как часть репозитория Git.

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

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

1. Если вы используете локальные средства выполнения тестов, перенастройте их.

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

2. Повторно добавьте зашифрованные секреты.

   • Сведения об использовании браузера см. в разделе Зашифрованные секреты.
   • Сведения об использовании GitHub CLI см gh secret . в документации по GitHub CLI.

3. Перенастройка сред. Дополнительные сведения см. в разделе Использование сред для развертывания.

Настройка списков разрешенных IP-адресов

Если вы добавили диапазоны IP-адресов для GitHub Enterprise Importer в списки разрешенных IP-адресов для исходных или целевых организаций, эти записи можно удалить. Если вы отключили ограничения списка разрешенных IP-адресов поставщика удостоверений для целевого предприятия, их можно снова включить.

Дополнительные сведения см. в разделе Управление доступом для GitHub Enterprise Importer.

Управление функцией «GitHub Advanced Security»

Если вы включили GitHub Advanced Security для целевой организации перед переносом репозиториев, параметры для отдельных функций были перенесены. В противном случае вам потребуется повторно включить отдельные функции после миграции. Дополнительные сведения см. в разделе Управление параметрами безопасности и анализа для репозитория.

Для каждой функции необходимо выполнить дополнительные действия после миграции.

Secret scanning

Если для целевого репозитория включено сканирование секретов, будет выполнено сканирование всего репозитория. После завершения сканирования будут заполнены все оповещения, но без состояний исправления.

Вы можете использовать REST API для обновления оповещений, чтобы зеркало исправления в исходном репозитории. Дополнительные сведения см. в разделе Сканирование секретов в документации по REST API.

Пользователь, связанный с этими обновленными исправлениями, будет владельцем personal access token, который использовался для вызовов API, а не пользователем, который исправил оповещение в исходном репозитории, а датой, связанной с исправлением, будет дата вызова API, а не дата исправления оповещения в исходном репозитории.

Code scanning

Code scanning оповещения не переносятся GitHub Enterprise Importer. Однако оповещения доступны в виде данных SARIF в исходном репозитории. Для отправки этих данных в целевой репозиторий можно использовать REST API. Дополнительные сведения см. в разделе "Проверка кода" в документации по REST API.

Оповещения Code scanning, которые заполняются таким образом, будут отличаться от исходных оповещений в исходном репозитории.

• Оповещения будут включать только обнаружение и последнее состояние оповещения, а не все временная шкала из исходного репозитория.
• Оповещения будут идентифицироваться только как open или fixed. Другие состояния исправления, такие как dismissed и reopened, будут потеряны.
• Даты всех событий в оповещении будут датой вызова API, а не датами первоначального возникновения событий в исходном репозитории.
• Все субъекты, например создатель оповещений, перейдут на владельца personal access token, используемого для вызова API.

Dependabot alerts

Если Dependabot alerts и граф зависимостей включены, Dependabot alerts будет перестроено из текущего состояния ветвь по умолчанию. Состояния исправления этих оповещений не переносятся, а все предыдущие оповещения также не переносятся.

Вам потребуется повторно добавить зашифрованные секреты для Dependabot. Дополнительные сведения см. в разделе Настройка доступа к частным реестрам для Dependabot.

Включение веб-перехватчиков

Переносятся все активные веб-перехватчики в исходном репозитории. Однако перенесенные веб-перехватчики по умолчанию будут отключены. Вы можете повторно включить эти веб-перехватчики в параметрах репозитория.

1. Перейдите к параметрам перенесенного репозитория.
2. В разделе "Код и автоматизация" на боковой панели щелкните Веб-перехватчики.
3. Справа от веб-перехватчика, который вы хотите включить, щелкните Изменить.
4. Если вы использовали секретный маркер для защиты веб-перехватчика, в разделе "Секрет" повторно добавьте секрет.
5. В нижней части страницы выберите Активный.
6. Щелкните Обновить веб-перехватчик.

Переустановка GitHub Apps

Если в исходном репозитории установлены GitHub Apps, их необходимо переустановить в перенесенном репозитории. Дополнительные сведения см. в разделе Установка собственного Приложение GitHub.

Воссоздание команд

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

Повторное выполнение команд для миграции организации

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

Мы настоятельно рекомендуем использовать синхронизацию команд для управления членством в команде с помощью поставщика удостоверений (IdP). Дополнительные сведения см. в разделе Настройка подготовки SCIM для Enterprise Managed Users или для предприятий, которые не используют Enterprise Managed Users, Управление синхронизацией команд для организаций на предприятии.

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

Повторное выполнение команд для миграции репозитория

Teams не переносятся в рамках миграции репозитория. Необходимо вручную создать команды и предоставить каждой команде доступ к репозиторию.

1. Повторно создайте команды. Дополнительные сведения см. в разделе Создание команды.
2. Добавление участников организации в команды. Дополнительные сведения см. в разделе Добавление участников организации в команду.
3. Предоставьте каждой команде доступ к репозиторию. Дополнительные сведения см. в разделе Управление доступом команды к репозиторию организации.

Восстановление манекенов

После выполнения миграции с GitHub Enterprise Importer все действия пользователей в перенесенном репозитории (за исключением фиксаций Git) относятся к удостоверениям заполнителей, называемым манекены.

Вы можете повторно отправить журнал для каждого манекена участнику организации, отправив приглашение на присвоение с GitHub CLI или в браузере. Если вы используете GitHub CLI, вы можете массово освободить манекены. Дополнительные сведения см. в разделе Освобождение манекенов для GitHub Enterprise Importer.

1. Решите, хотите ли вы вернуть манекены.
2. Запланируйте, когда вы завершите освобождение.
3. Вернуть манекены.
4. Если какой-либо из участников еще не имеет соответствующего доступа к репозиторию через членство в команде, предоставьте им доступ к репозиторию. Дополнительные сведения см. в разделе Управление доступом пользователя к репозиторию организации.