Обзор миграции между продуктами GitHub

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

В этой статье

Обзор

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

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

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

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

Нужно ли выполнить миграцию по организации или по репозиторию?

Во-первых, если источник миграции и назначение являются GitHub.com, определите, следует ли выполнять миграцию на основе организации или на основе репозитория по репозиторию.

Примечание. При миграции из GitHub Enterprise Serverможно перенести только репозитории.

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

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

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

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

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

  • Число репозиториев
  • Количество запросов на вытягивание
  • Количество проблем
  • Число пользователей
  • Использование проектов и вики-сайтов

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

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

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

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

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

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

Выбор того, кто будет выполнять миграции организации

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

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

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

Выбор того, кто будет запускать миграции репозитория

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

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

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

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

Нужно ли поддерживать аналогичную структуру организации после миграции?

Затем рассмотрим, следует ли поддерживать аналогичную структуру организации после миграции. Если вы хотите разбить усилия миграции на пакеты, это поможет вам определить пакеты. Если вы планируете сохранить одно-одно соответствие между организациями в исходном и целевом расположении, рекомендуется пакетная миграция по организации. Это самый простой подход, особенно при миграции из GitHub.com, так как вы можете перенести всю организацию с одной командой. При миграции из другого источника GitHub CLI может создать скрипт для переноса всех репозиториев в одной организации.

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

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

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

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

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

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

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

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

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

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

  1. Если вы выполняете миграцию репозитория, создайте тестовую организацию для пробной миграции.
  2. Если в исходной организации используются списки разрешенных IP-адресов, настройте список, чтобы разрешить доступ к данным GitHub Enterprise Importer. Дополнительные сведения см. в разделе Управление доступом к миграции между продуктами GitHub.
  3. Запустите пробные миграции.
  4. Выполните следующие задачи, описанные ниже для миграции пробных версий.
  5. Попросите пользователей проверить результаты миграции.
  6. Устраните все проблемы, обнаруженные миграцией пробной версии.
  7. Если назначение использует списки разрешенных IP-адресов, настройте список, чтобы разрешить доступ с помощью GitHub Enterprise Importer. Дополнительные сведения см. в разделе "Управление доступом к миграции между продуктами GitHub".
  8. Если вы выполняете миграцию репозитория и хотите перенести параметры GitHub Advanced Security включите GitHub Advanced Security для целевой организации. Дополнительные сведения см. в разделе Управление параметрами безопасности и анализа для организации.
  9. Запустите рабочие миграции. Дополнительные сведения см. в разделе "[AUTOTITLE" илиСведения о GitHub Enterprise Importer](/migrations/using-github-enterprise-importer/migrating-organizations-with-github-enterprise-importer)".
  10. При необходимости удалите тестовую организацию.

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

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

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

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

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

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

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

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

Перенос объектов Git LFS

GitHub Enterprise Importer не переносит объекты Git LFS . Если исходный репозиторий использует Git LFS, можно вручную отправить объекты Git LFS в перенесенный репозиторий локально. Дополнительные сведения см. в разделе Дублирование репозиториев.

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

Настройка GitHub Actions

Если вы используете GitHub Actions в репозитории, рабочие процессы автоматически переносятся в составе репозитория Git.

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

Если вы использовали крупное средство выполненияs, локальные модули выполнения или зашифрованные секреты, их необходимо перенастроить.

Примечание. Журнал выполнения рабочего процесса для GitHub Actions не включен в миграции.

  1. Если вы используете локальные модули выполнения, перенастройьте их.

  2. Если вы используете крупное средство выполненияs, перенастройьте средства выполнения.

  3. Повторно добавьте все зашифрованные секреты.

  4. Перенастройка сред. Дополнительные сведения см. в разделе Использование сред для развертывания.

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

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

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

Управление функцией «GitHub Advanced Security»

Если вы включили GitHub Advanced Security для целевой организации перед переносом репозиториев, параметры отдельных функций были перенесены. В противном случае необходимо повторно включить отдельные функции после миграции. Дополнительные сведения см. в разделе Управление параметрами безопасности и анализа для репозитория.

Для каждой функции существуют дополнительные шаги после миграции.

Secret scanning

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

Rest API можно использовать для обновления оповещений, чтобы зеркало любые исправления в исходном репозитории. Дополнительные сведения см. в разделе Конечные точки REST API для проверки секретов.

Пользователь, связанный с этими обновленными исправлениями, будет пользователем, которому принадлежит personal access token, который использовался для вызовов API, а не пользователь, который исправил оповещение в исходном репозитории, а дата, связанная с исправлением, будет датой вызова API, а не датой, когда оповещение было исправлено в исходном репозитории.

Code scanning

Оповещения Code scanning не переносятся GitHub Enterprise Importer. Однако оповещения доступны в качестве данных SARIF в исходном репозитории. REST API можно использовать для отправки этих данных в целевой репозиторий. Дополнительные сведения см. в разделе Конечные точки REST API для сканирования кода.

Оповещения Code scanning, заполненные таким образом, будут отличаться от исходных оповещений в исходном репозитории.

  • Оповещения будут включать только обнаружение и последнее состояние оповещения, а не все временная шкала из исходного репозитория.
  • Оповещения будут идентифицироваться только как open или fixed. Другие состояния исправления, такие как dismissed и reopened, будут потеряны.
  • Даты всех событий в оповещении будут датой вызова API, а не датами, когда события первоначально произошли в исходном репозитории.
  • Все субъекты, такие как создатель оповещений, будут изменены на владельца personal access token, используемых для вызова API.

Dependabot alerts

Если Dependabot alerts и граф зависимостей включены, Dependabot alerts будет перестроено из текущего состояния ветвь по умолчанию. Состояния исправления этих оповещений не переносятся, а предыдущие оповещения также не переносятся.

Вам потребуется повторно добавить все зашифрованные секреты для Dependabot. Дополнительные сведения см. в разделе Настройка доступа к частным реестрам для Dependabot.

Включение веб-перехватчиков

Переносятся все активные веб-перехватчики в исходном репозитории. Однако перенесенные веб-перехватчики будут отключены по умолчанию. Эти веб-перехватчики можно повторно включить в параметрах репозитория.

  1. Перейдите к параметрам перенесенного репозитория.
  2. В разделе "Код и автоматизация" боковой панели щелкните веб-перехватчики.
  3. Справа от веб-перехватчика, который вы хотите включить, нажмите кнопку "Изменить".
  4. Если вы использовали секретный токен для защиты веб-перехватчика, в разделе "Секрет" повторно добавьте секрет.
  5. В нижней части страницы выберите "Активный".
  6. Щелкните Обновить веб-перехватчик.

Переустановка GitHub Apps

Если в исходном репозитории установлены данные GitHub Apps, необходимо переустановить их в перенесенном репозитории. Дополнительные сведения см. в разделе Установка собственного приложения GitHub.

Воссоздание команд

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

Повторная подготовка команд для миграции организации

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

Мы настоятельно рекомендуем использовать синхронизацию команд для управления членством в команде через поставщика удостоверений (IdP). Дополнительные сведения см. в разделе "[AUTOTITLE" или для предприятий, которые не используют Enterprise Managed Users, "Настройка подготовки SCIM для Enterprise Managed Users](/enterprise-cloud@latest/admin/identity-and-access-management/using-saml-for-enterprise-iam/managing-team-synchronization-for-organizations-in-your-enterprise)".

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

Воссоздание команд для миграции репозиториев

Teams не переносятся в рамках миграции репозитория. Необходимо вручную создать команды и предоставить каждому команду доступ к репозиторию.

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

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