Обзор миграции из Azure DevOps в GitHub Enterprise Cloud

Обзор

С помощью 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?

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

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

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

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

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

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

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

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

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

Кто будет запускать миграцию?

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

1. Определите, требуется ли владелец организации целевой организации выполнить миграцию или предоставить роль миграции другому пользователю. Дополнительные сведения см. в разделе "Управление доступом к миграции из Azure DevOps". Дополнительные сведения см. в разделе "Управление доступом к миграции из Azure DevOps".

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

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

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

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

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

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

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

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

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

Миграции пробных версий помогают определить несколько критически важных элементов информации.

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

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

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

1. Создайте тестовую организацию для пробной миграции.
2. Запустите пробные миграции.
3. Выполните следующие задачи, описанные ниже для миграции пробных версий.
4. Попросите пользователей проверить результаты миграции.
5. Устраните все проблемы, обнаруженные миграцией пробной версии.
6. Если назначение использует списки разрешенных IP-адресов, настройте список, чтобы разрешить доступ с помощью GitHub Enterprise Importer. Дополнительные сведения см. в разделе "Управление доступом к миграции из Azure DevOps".
7. Запустите рабочие миграции. Дополнительные сведения см. в разделе Перенос репозиториев из Azure DevOps в GitHub Enterprise Cloud.
8. При необходимости удалите тестовую организацию.

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

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

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

Проверка состояния миграции

Сначала проверьте успешность или сбой миграции.

Способ проверки состояния миграции зависит от способа запуска миграции.

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

  Migration completed (ID: RM_123)! State: SUCCEEDED
  

• Если вы выполнили миграцию с помощью GitHub CLI с необязательным --queue-only аргументом, процесс завершится сразу после очереди миграции и не сообщит вам, успешно ли выполнена миграция или произошел сбой. Вы можете проверить состояние миграции с помощью wait-for-migration команды или просмотреть журнал миграции.

• Если вы выполнили миграцию с помощью API GraphQL, вы можете запросить state поля и failureReason поля объекта RepositoryMigration .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе Управление доступом к миграции из Azure DevOps.