Фаза 4. Подготовьтесь к миграции с Azure DevOps на GitHub

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

В этой статье

Определите, сколько вам нужно мигрировать

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

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

Примечание.

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

Рекомендуем команду inventory-report в ADO2GH extension of the GitHub CLI. Эта команда подключается к Azure DevOps API, а затем создаст несколько CSV-файлов. repos.csv содержит информацию о ваших репозиториях, включая количество pull request.

Чтобы создать CSV-файлы, используйте следующую команду, заменяя YOUR_ADO_ORG их на вашу организацию в Azure DevOps.

Shell
gh ado2gh inventory-report --ado-org YOUR_ADO_ORG

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

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

Определите структуру организации GitHub

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

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

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

Примечание.

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

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

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

Настройка разрешений репозитория

Так как разрешения работают по-разному в GitHub, чем в ADO, GitHub Enterprise Importer не пытается перенести разрешения репозитория из ADO.

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

КомандаДоступ к перенесенным репозиториям
КОМАНДА —PROJECT-MaintainersПоддерживающий
КОМАНДА —PROJECT-AdminsАдминистратор

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

Дальнейшие шаги

На следующем этапе вы проведёте пробный запуск, а затем переместите свои репозитории. См . раздел AUTOTITLE.