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

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

Run your migration

Статья 2 из 7
Следующий:Управление доступом для миграции из GitLab в GitHub

В этой статье

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

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

  • Количество репозиториев (проектов)
  • Количество запросов на слияние

Примечание.

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

Рекомендуем команду inventory-report в GL2GH extension of the GitHub CLI. Эта команда подключается к API GitLab и создает два CSV-файла. groups.csv выводит список групп GitLab и projects.csv выводит список проектов, включая количество запросов на слияние.

Чтобы создать CSV-файлы, используйте следующую команду, заменив GITLAB_SERVER_URL URL-адрес сервера GitLab (например, ) и YOUR_GITLAB_GROUP группу, https://gitlab.comо которой вы хотите сообщить. Чтобы сообщить обо всех проектах, к которые можно получить доступ, опустить --gitlab-group. Для всех доступных параметров выполните команду gh gl2gh inventory-report --help.

Shell
gh gl2gh inventory-report --gitlab-server-url GITLAB_SERVER_URL --gitlab-group YOUR_GITLAB_GROUP

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

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

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

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

  • GitLab: группы > экземпляров > подгрупп (которые могут быть вложены до 20 уровней глубоко) > проектов (репозитории)
  • GitHub: корпоративные > организации > репозитории

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

Примечание.

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

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

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

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

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

В GitLab члены предоставляются роли (например, "Гостевой", "Репортер", "Разработчик", "Обслуживание" или "Владелец") на уровне группы, подгруппы или проекта, а эти роли наследуются по иерархии. Эти роли не сопоставляются напрямую GitHub, поэтому после миграции вам потребуется повторно создать доступ.

Чтобы предоставить пользователям доступ к перенесенным репозиториям GitHub, рекомендуется создавать команды и предоставлять каждой команде соответствующий уровень доступа к соответствующим организациям и репозиториям. Затем вы можете добавить людей в эти команды. См . раздел AUTOTITLE.