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

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

Если вы перемещаетесь между продуктами GitHub, например с GitHub Enterprise Server на GitHub Enterprise Cloud, или из другой платформы размещения кода, например Bitbucket Server или GitLab, на GitHub, вы хотите принести с вами работу: ваш код, журнал кода, а также все прошлые беседы и совместную работу.

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

Терминология миграции

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

Термин	Определение
Платформа размещения кода	Онлайн-инструмент, используемый для размещения репозиториев исходного кода и совместной работы, таких как GitHub Enterprise Cloud, GitHub Enterprise Server, Bitbucket Server и GitLab.com.
Система управления версиями (VCS)	Средство, используемое для отслеживания изменений и управления ими в исходном коде на компьютере, где вы вносите эти изменения. Например, если вы используете GitHub или GitLab в качестве платформы размещения кода, вы используете систему управления версиями Git. Если вы используете Azure DevOps в качестве платформы размещения кода, вы можете использовать Git или система управления версиями Team Foundation (TFVC) в качестве базовой системы управления версиями. Также возможно, что вы не используете VCS вообще.
Источник миграции	Место, из который выполняется миграция. Как правило, это будет платформа размещения кода, но это может быть собственный компьютер или общий сетевой диск.
Назначение миграции	Продукт GitHub, на который вы переходите.
Путь перехода	Сочетание источника миграции и назначения миграции, например "Bitbucket Server до GitHub Enterprise Cloud". Для определенных путей миграции GitHub предлагает специальные инструменты, такие как GitHub Enterprise Importer, чтобы помочь вам выполнить миграцию.

Определение области миграции

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

Определение источника и назначения

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

Платформа размещения кода может быть продуктом GitHub, например GitHub.com или GitHub Enterprise Server, или может быть другой платформой размещения кода, например Bitbucket Server, GitLab или Azure DevOps. В зависимости от размера и сложности вашего бизнеса вы можете использовать несколько разных платформ размещения кода.

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

Где бы ни находились код, это ваш "источник миграции".

Кроме того, вам потребуется знать, какой продукт GitHub вы переносите или "назначение миграции". Это может быть GitHub.com, GHE.comили GitHub Enterprise Server.

Создание базовой инвентаризации репозиториев, которые требуется перенести

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

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

• Имя.
• Владелец: в GitHub, это будет организация, но в других средствах может быть другой тип владельца.
• URL
• Метка времени последнего обновления
• Количество запросов на вытягивание (или эквивалент в источнике миграции)
• Количество проблем (или эквивалентных в источнике миграции)

Если вы переносите данные GitHub Enterprise Cloud или GitHub Enterprise Server, вы можете получить эти данные с расширением gh-repo-stats для GitHub CLI. С помощью нескольких gh-repo-stats команд подключитесь к API источника миграции и создадите CSV-файл со всеми рекомендуемыми полями. Дополнительные сведения см. в репозитории mona-actions/gh-repo-stats .

При миграции из Azure DevOps рекомендуется inventory-report выполнить команду в ADO2GH extension of the GitHub CLI. Команда inventory-report будет подключаться к API Azure DevOps, а затем создать простой CSV-файл с некоторыми полями, предложенными выше. Дополнительные сведения об установке ADO2GH extension of the GitHub CLIсм. в разделе "Перенос репозиториев из Azure DevOps в GitHub Enterprise Cloud".

Если вы выполняете миграцию из Bitbucket Server или Bitbucket Data Center, мы рекомендуем inventory-report команду в BBS2GH extension of the GitHub CLI. Команда inventory-report будет использовать API экземпляра Bitbucket для создания простого CSV-файла. Дополнительные сведения об установке BBS2GH extension of the GitHub CLIсм. в разделе "Перенос репозиториев из Bitbucket Server в GitHub Enterprise Cloud".

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

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

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

Измерение размеров репозиториев

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

Если вы используете Git в качестве системы управления версиями, это не только большие файлы в репозитории, которые имеют значение; Большие файлы в журнале репозитория также имеют значение. Например, если у вас есть файл размером более 100 МБ в репозитории в прошлом, этот файл по-прежнему будет присутствовать в журнале Git, если только вы не перезаписали журнал, чтобы удалить все трассировки файла. Дополнительные сведения о перезаписи журнала см. в разделе "Сведения о больших файлах на GitHub".

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

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

• Размер крупнейшего файла (также известного как большой двоичный объект)
• Общий размер всех файлов ("BLOB-объектов")

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

Затем используйте средство с открытым кодом, git-sizerчтобы получить эти данные для репозитория.

Необходимые компоненты

1. Установите git-sizer. Дополнительные сведения см. в репозитории github/git-sizer .
2. Чтобы убедиться, что git-sizer установлен, выполните команду git-sizer –version. Если вы видите такие выходные данные git-sizer release 1.5.0, установка выполнена успешно.
3. Установите jq. Дополнительные сведения см. в разделе "Скачать jq " в jq документации.
4. Чтобы убедиться, что jq установлен, выполните команду jq –-version. Если вы видите такие выходные данные jq-1.6, установка выполнена успешно.

Измерение размера репозитория с помощью git-sizer

1. Чтобы клонировать репозиторий из источника миграции, выполните команду git clone --mirror.
2. Перейдите в каталог, в котором клонировали репозиторий.
3. Чтобы получить размер крупнейшего файла в репозитории в байтах, выполните команду git-sizer --no-progress -j | jq ".max_blob_size".
4. Чтобы получить общий размер всех файлов в репозитории в байтах, выполните команду git-sizer --no-progress -j | jq ".unique_blob_size".
5. Добавьте значения из предыдущих шагов в инвентаризацию.

Сведения о типах миграции

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

Тип переноса	Определение	Требования
Моментальный снимок источника	Перенесите текущее состояние кода, так как это сейчас, но не включайте ни один из журналов редакций.	Возможно для каждого источника и назначения, даже если код в настоящее время не отслеживается в системе управления версиями (VCS).
Источник и журнал	Перенос текущего состояния кода и его журнала редакций.	Возможно, если вы отслеживали изменения в Git или систему управления версиями, которую можно преобразовать в Git до миграции.
Исходные, журналы и метаданные	Перенос текущего состояния кода и его журнала редакции, а также журнала совместной работы, таких как проблемы и запросы на вытягивание, а также параметры.	Требуется специализированные средства, которые недоступны для всех путей миграции.

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

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

О различных моделях поддержки миграции

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

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

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

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

Выбор используемых средств

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

Проектирование структуры организации для назначения миграции

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

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

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

Выполнение миграции с сухим запуском для каждого репозитория

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

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

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

Планирование шагов до миграции и после миграции

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

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

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

Существуют также этапы после миграции, которые применяются ко всем миграциям:

• Сообщите пользователям, что миграция завершена
• Связывание действий с пользователями в назначении миграции
• Вывод из эксплуатации источника миграции

Ниже приведены некоторые другие шаги, которые следует учитывать при планировании миграции.

Миграция непрерывной интеграции (CI) и непрерывной доставки (CD)

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

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

Если вы планируете переключиться на GitHub Actions, мы не рекомендуем делать это одновременно с переносом репозиториев. Вместо этого подождите до более поздней даты и выполните миграцию CI/CD в качестве отдельного шага. Это делает процесс миграции более управляемым. Когда вы будете готовы к миграции, см. разделПереход на GitHub Actions".

Миграция интеграции

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

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

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

Связывание действий с пользователями в назначении миграции

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

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

Способ работы атрибуции отличается между инструментами:

• Если вы используете ghe-migratorили gl-exporter``bbs-exporterхотите заранее атрибутировать данные и включить файл сопоставления при импорте данных.
• Если вы используете GitHub Enterprise Importer, данные будут связаны с удостоверениями заполнителей под названием "манекены", и вы можете назначить этот журнал реальным пользователям после переноса данных. Дополнительные сведения см. в разделе Восстановление манекенов для GitHub Enterprise Importer.

Управление командами и разрешениями

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

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

Однако вы не можете присоединить команды к репозиториям до тех пор, пока вы не перенесли репозитории.