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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Используйте расширение для GitHub CLI, а затем просмотрите gh-repo-stats инвентаризацию миграции.
2. Чтобы понять, когда команды могут быть готовы к миграции, интервью заинтересованных лиц.
3. Полностью просмотрите остальную часть этого руководства, а затем определите временную шкалу миграции.

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

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

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

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

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

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

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

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

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

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

3. Убедитесь, что пользователь правильно настроил personal access tokens в соответствии со всеми требованиями к доступу. Для получения дополнительной информации см. Управление доступом к миграции между продуктами GitHub.

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

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

1. Определите, хотите ли вы выполнить миграцию владелец организации или предоставить роль миграции другому пользователю.

2. Если вы решили предоставить роль миграции, решите, какой человек или команда вы предоставите роль.

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

   Примечание.

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

4. Убедитесь, что пользователь правильно настроил personal access tokens в соответствии со всеми требованиями к доступу. Для получения дополнительной информации см. Управление доступом к миграции между продуктами GitHub.

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

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

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

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

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

Что такое наш план для имен предприятий и организаций?

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

Учетные записи организаций в GitHub Enterprise одном и том же пространстве имён; два учетных записи пользователя/организации не могут иметь одинаковое имя. Корпоративные аккаунты на GitHub Enterprise одном и том же пространстве имён; два корпоративных аккаунта не могут иметь одинаковое имя.

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

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

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

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

Для миграций репозитория рекомендуется создать тестовую организацию для использования в качестве назначения для пробных миграций. Вы можете использовать одну организацию для всех пробных запусков или создать одну тестовую организацию для каждой целевой организации. Рассмотрите возможность включения -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. При необходимости удалите тестовую организацию.

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

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

• Проверка состояния миграции
• Просмотр журнала миграции
• Мигрирующие Git LFS (Git Large File Storage — поддержка хранения больших файлов в Git) объекты
• Настройка видимости репозитория
• Настройка GitHub Actions
• Настройка списков разрешений IP-адресов
• Управляющие GitHub Advanced Security особенностями
• Включение веб-перехватчиков
• Переустановка GitHub Apps
• Воссоздание команд
• Восстановление манекенов

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

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

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

• Если вы выполнили миграцию с помощью 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. После просмотра предупреждений о миграции необходимо принять решение о том, можно ли принять эти предупреждения и перейти вперед.

Мигрирующие Git LFS (Git Large File Storage — поддержка хранения больших файлов в Git) объекты

GitHub Enterprise Importer не мигрирует Git LFS (Git Large File Storage — поддержка хранения больших файлов в Git) объекты. Если исходный репозиторий использует Git LFS (Git Large File Storage — поддержка хранения больших файлов в Git), можно вручную Git LFS (Git Large File Storage — поддержка хранения больших файлов в Git) отправлять объекты в мигрированный репозиторий локально. Дополнительные сведения см. в разделе Дублирование репозиториев.

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

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

• Вы можете изменить видимость репозитория в браузере. Дополнительные сведения см. в разделе Настройка видимости репозитория.
• В качестве альтернативы можно GitHub CLI изменить видимость репозитория из командной строки. Для получения дополнительной информации см. gh repo edit в GitHub CLI документации.

Настройка GitHub Actions

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

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

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

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

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

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

   • Настройте группы runner для управления доступом к бегунам. Дополнительные сведения см. в разделе Управление доступом к крупным средствам выполнения.
   • Настройте свой крупное средство выполненияS. Дополнительные сведения см. в разделе Управление большими бегунами.
   • Обновите рабочие процессы, чтобы указать на бегунов. Дополнительные сведения см. в разделе Выполнение заданий на более крупных запусках.

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

   • Сведения об использовании браузера см. в разделе Использование секретов в GitHub Actions.
   • Для использования GitHub CLIсм. gh secret в GitHub CLI документации.

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

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

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

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

Управляющие GitHub Advanced Security особенностями

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

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

Secret scanning

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

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

Пользователь, связанный с этими обновленными исправлениями, будет владельцем 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.

Перенастройка функций для Место расположения данных

Если вы перешли с GitHub.com в GitHub Enterprise Cloud с размещением данных, некоторые функции работают иначе, а некоторые потребуют другой или дополнительной конфигурации. См . раздел AUTOTITLE.

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

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

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

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

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

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

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

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

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

Мы настоятельно рекомендуем использовать синхронизацию команд для управления членством в команде через поставщика удостоверений (IdP). Для получения дополнительной информации см. Настройка SCIM-предоставления пользователей Enterprise для управления пользователями или, для предприятий, которые не используют Enterprise Managed Users, AUTOTITLE.

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

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

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

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

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

После запуска перехода с GitHub Enterprise Importer или Enterprise Live Migrations, вся пользовательская активность в мигрированном репозитории (кроме Git-коммитов) приписывается временным идентичностям, называемым манекенами.

1. Решите, хотите ли вы восстановить манекины.
2. Запланируйте, когда вы завершите восстановление.
3. Восстановление манекенов. Вы можете переопределить историю каждого манекена члену организации с помощью GitHub CLI или в браузере. Если вы используете GitHub CLI, вы сможете восстановить манекены оптом. Дополнительные сведения см. в разделе Восстановление манекенов для GitHub Enterprise Importer.
4. Если любой из членов еще не имеет соответствующего доступа к репозиторию через членство в команде, предоставьте членам доступ к репозиторию. Дополнительные сведения см. в разделе Управление доступом пользователя к репозиторию организации.