Эта версия GitHub Enterprise Server была прекращена 2024-07-09. Исправления выпускаться не будут даже при критических проблемах безопасности. Для повышения производительности, повышения безопасности и новых функций выполните обновление до последней версии GitHub Enterprise Server. Чтобы получить справку по обновлению, обратитесь в службу поддержки GitHub Enterprise.

Обзор миграции с Bitbucket Server на GitHub Enterprise Cloud

Узнайте о процессе миграции с Bitbucket Server на GitHub с GitHub Enterprise Importer, от планирования до выполнения последующих задач.

В этой статье

Обзор

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

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

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

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

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

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

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

Время миграции в основном основано на количестве запросов на вытягивание в репозитории. Если вы хотите перенести 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. Дополнительные сведения см. в разделе Сведения о миграции с Bitbucket Server на GitHub Enterprise Cloud.
  2. Создайте список любых данных, которые потребуется вручную перенести или повторно создать.

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

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

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

  • Разрешения администратора или суперадминистраторов
  • Если экземпляр Bitbucket Server запускает Linux, доступ SFTP к экземпляру с помощью поддерживаемого закрытого ключа SSH (см. "AUTOTITLE")
  • Если экземпляр Bitbucket Server запускает Windows, доступ к экземпляру общего доступа к файлу (SMB)
  1. Определите, требуется ли владелец организации целевой организации выполнить миграцию или предоставить роль миграции другому пользователю. Дополнительные сведения см. в разделе "Управление доступом к миграции с сервера Bitbucket". Дополнительные сведения см. в разделе "Управление доступом к миграции с сервера Bitbucket".
  2. Убедитесь, что миграция имеет разрешения администратора или суперадминистратора и доступ SFTP для экземпляра сервера Bitbucket.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Если вы выполнили миграцию с помощью 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, чем в Bitbucket Server, GitHub Enterprise Importer не пытается перенести разрешения репозитория из Bitbucket Server.

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

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

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

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

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

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