Миграция с Bitbucket Server с помощью GitHub Enterprise Importer

Сведения о миграциях с Bitbucket Server

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

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

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

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

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

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

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

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

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

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

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

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

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

При миграции с Bitbucket Server GitHub Enterprise Importer переносит только репозитории Git и запросы на вытягивание. Все другие ресурсы, такие как конвейеры CI, останутся на сервере Bitbucket.

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

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

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

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

Вы также должны иметь необходимые разрешения и доступ к экземпляру Bitbucket Server:

• разрешения Администратор или суперадминистраторов
• Если экземпляр Bitbucket Server работает под управлением Linux, доступ по протоколу SSH к экземпляру с помощью поддерживаемого закрытого ключа (см. раздел Управление доступом для GitHub Enterprise Importer).
• Если экземпляр Bitbucket Server работает под управлением Windows, доступ к экземпляру общего доступа к файлам (SMB)

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

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

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

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

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

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

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

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. Выполните миграцию в рабочей среде. Дополнительные сведения см. в разделе Перенос репозиториев с Bitbucket Server в 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 работают иначе, чем в Bitbucket Server, GitHub Enterprise Importer не пытается перенести разрешения репозитория с bitbucket Server.

Чтобы предоставить доступ к перенесенным репозиториям, можно создать команды и предоставить каждой команде доступ к репозиторию.

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

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

После выполнения миграции с 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.