Миграция из Azure DevOps с помощью GitHub Enterprise Importer

Сведения о миграции из Azure DevOps

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

Если вы выполняете миграцию из Azure DevOps (ADO), вы можете использовать это руководство для планирования и реализации миграции и выполнения последующих задач.

Предприятия, которые переходируют с ADO на GitHub, обычно используют многоэтапный подход.

1. Перенос репозиториев из ADO в GitHub.
2. Перенос конвейеров из Azure Pipelines в GitHub Actions.
3. Перенос оставшихся ресурсов, таких как доски и артефакты, из ADO в GitHub.

В этом руководстве описано, как выполнить первый этап, перенести репозитории в GitHub, и предполагается, что вы используете ADO2GH extension of the GitHub CLI.

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

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

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

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

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

• Число репозиториев
• Количество запросов на вытягивание

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

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

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

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

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

Для миграций из ADO GitHub Enterprise Importer переносит только репозитории Git, включая запросы на вытягивание и некоторые политики ветви. Все другие ресурсы, такие как конвейеры, рабочие элементы, артефакты, планы тестирования, выпуски и панели мониторинга, останутся в ADO.

Так как разрешения в GitHub работают иначе, чем в ADO, GitHub Enterprise Importer не пытается перенести разрешения репозитория из ADO. Дополнительные сведения см. в разделе Настройка разрешений.

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

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

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

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

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

Какая организационная структура нам нужна в GitHub?

Затем спланируйте организационную структуру, которую вы создадите в GitHub. ADO и GitHub имеют разные способы организации работы предприятия.

• ADO: командный проект организации > > репозитории
• GitHub: репозитории организации > enterprise >

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

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

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

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

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

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

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

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

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

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

1. Создайте тестовую организацию для пробных миграций.
2. Run the trial migrations. For more information, see "Подготовка к выполнению миграции с помощью GitHub Enterprise Importer."
3. Complete the follow-up tasks described below for the trial migrations.
4. Ask users to validate the results of the migrations.
5. 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."
6. Выполните миграцию в рабочей среде. Дополнительные сведения см. в разделе Перенос репозиториев из Azure DevOps в GitHub Enterprise Cloud.
7. При необходимости удалите тестовую организацию.

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

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

• Просмотр журнала миграции
• Настройка видимости репозитория
• Настройка разрешений
• Восстановление манекены
• Настройка списков разрешенных IP-адресов

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

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

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

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

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

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 работают иначе, чем в ADO, GitHub Enterprise Importer не пытается перенести разрешения репозитория из ADO.

Если вы использовали ADO2GH CLI, GitHub Enterprise Importer создаст две команды в GitHub для каждого командного проекта в ADO. Каждой команде предоставляется отдельный уровень доступа ко всем репозиториям, полученным из командного проекта.

Группа	Доступ к перенесенным репозиториям
Участники team-project-поддержки	Ответственный за команду
Администраторы TEAM-PROJECT	Административный

Чтобы предоставить доступ к перенесенным репозиториям, можно добавить людей в эти команды. Это можно сделать вручную на GitHub или, если вы решили связать команды с группами Azure Active Directory (AAD) во время миграции, управляя членством в группах В AAD. Дополнительные сведения об управлении членством в команде вручную см. в разделе Добавление участников организации в команду.

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

1. Решите, какая структура разрешений требуется в GitHub.
2. Если значение отличается от значения по умолчанию, создайте план настройки членства в команде и разрешений.

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

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

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

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

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

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

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