Пошаговое руководство по переходу от Perforce к Git

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

Перенос данных из Perforce
Сопоставление пользователей и прав в новом репозитории Git
Большие двоичные файлы
Сложные зависимости
Структурирование команды во время миграции
Зеркалирование данных
Инструменты ALM
Определение успешности миграции из Perforce в Git

Шаг 1. Перенос данных из Perforce

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

Сервер Perforce может содержать десятки или сотни отдельных программных проектов, каждый со своей моделью ветвления. Разработчик определяет представление, которое диктует серверу Perforce, какие файлы поместить в рабочую копию. Напротив, репозиторий Git, как правило, содержит один программный проект, его ветки и теги (хотя существуют и большие монолитные репозитории Git). Обычно клонируется репозиторий и, возможно, извлекаются подмодули или поддеревья.

Таким образом, вопрос о переносе данных складывается из двух составляющих: как извлечь данные из Perforce и как конвертировать их в эквивалентный набор репозиториев Git.

Способ 1 для переноса данных из Perforce: использование Git Fusion

Если вы хотите сохранить всю историю своих данных в Perforce, можно использовать собственный инструмент Perforce — Git Fusion, чтобы извлечь раздел сервера Perforce (один проект) в репозиторий Git. По сути, вы делаете следующее.

Устанавливаете Git Fusion.
Настраиваете правильные представления данных, в том числе структуру ветвления.
Используете какой-нибудь клиент Git для клонирования из Git Fusion.
Отправляете свой репозиторий в Bitbucket

 Практический пример *Для работы с этим примером вам понадобится сервер Perforce с уже работающим инструментом Git Fusion.* Предположим, у вас есть проект Perforce, расположенный в репозитории //depot/acme/… (в синтаксисе представления депо Perforce). В нем есть три ветки: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Имейте в виду, что в Perforce ветки отображаются как дополнительные каталоги в дереве. Первым делом необходимо описать взаимосвязи ветвления Perforce в конфигурации Git Fusion. Для этого нужно создать файл конфигурации репозитория: [@repo] description = Acme project charset = utf8 [main] имя-ветки-git = main view = //depot/acme/main/… … [r1.0] имя-ветки-git = r1.0 view = //depot/acme/r1.0/… … [r1.1] имя-ветки-git = r1.1 view = //depot/acme/r1.1/… … Отправьте этот файл в Perforce по адресу //.git-fusion/repos/acme/p4gf_config Теперь создайте пустой проект под названием acme в Bitbucket с помощью обычных инструментов администрирования Bitbucket. Вы можете настроить контроль доступа и участников команды в соответствии со своими обычными стандартами. Далее клонируйте репозиторий из Git Fusion: git clone https:///acme cd acme git remote add bitbucket  git push –u --all bitbucket git push --tags Bitbucket И все! Теперь импортированная история должна отображаться в Bitbucket.

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

Следует иметь в виду, что даже если вы храните историю ветвления из устаревшей системы SCM за последние 10 лет, вы не обязаны использовать тот же рабочий процесс. В качестве первого практического шага следует рассмотреть внедрение таких рабочих процессов для функциональных веток, как Git-flow.

Плюсы и минусы

Требует больше всего работы по настройке и выполнению.
Сохраняет большую часть истории (позволяет закрыть устаревший сервер Perforce).
Сохраняет устаревшую модель ветвления в истории.

Способ 2 для переноса данных из Perforce: начать с нуля

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

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

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

 **Практический пример** Зайдите в рабочее пространство Perforce (каталог, на который переключена основная ветка с данными проекта) и выполните команду: p4 sync Так вы получите последнюю версию файлов. Теперь создайте пустой проект под названием acme в Bitbucket с помощью обычных инструментов администрирования Bitbucket. Вы можете настроить контроль доступа и участников команды в соответствии со своими обычными стандартами. Затем создайте новый репозиторий Git в своем рабочем пространстве и отправьте его в Bitbucket: git init . git remote add origin  git push –u --all origin git push --tags origin Теперь последний снимок состояния кода должен стать первым коммитом в новом проекте Bitbucket.

Плюсы и минусы

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

Шаг 2. Пользователи и права

Следующая задача после перемещения данных — сопоставление пользователей и прав с новыми проектами Bitbucket. Если для каталога пользователей используется LDAP, вы сэкономите некоторое время. В противном случае вы можете легко извлечь набор пользовательских аккаунтов из Perforce с помощью команды p4 users –o, а затем ввести их в Bitbucket по одному проекту за раз.

Конвертировать права Perforce в соответствующие права Bitbucket бывает сложно, поскольку в Perforce применяются детализированные сложные правила, позволяющие исключить доступ к отдельным файлам. Эта сложная схема прав является одной из причин, по которой на сервере Perforce могут быть задержки: каждая попытка доступа может приводить к тому, что сервер будет выполнять дорогостоящие вычисления на сложной структуре данных.

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

Шаг 3. Двоичные файлы

Если в Perforce у вас хранились двоичные большие объекты, продумайте, как управлять ими в Git. Можно попробовать Git LFS или просто использовать обычную систему управления артефактами. В любом случае не стоит вслепую отправлять большие двоичные объекты в репозиторий Git.

Шаг 4. Сложные зависимости

Рабочая копия Perforce может использовать копии данных из нескольких модулей, доступные только для чтения. В Git это делается либо с помощью подмодулей и поддеревьев, либо с помощью систем непрерывной интеграции/непрерывной поставки или управления артефактами. Здесь нет простого ответа, но некоторые инструменты импорта данных могут имитировать отношения подмодулей между репозиториями Git. Более подробно о том, как использовать подмодули или поддеревья, можно прочитать здесь: https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/.

Шаг 5. Структурирование команды во время миграции

Итак, на вашем сервере Perforce находится 100 проектов от 10 команд. У вас есть стратегия и набор инструментов миграции. Осталось запланировать окно обслуживания — и вперед!

Но… все не так просто.

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

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

Переносите команду за командой и проект за проектом. Запланируйте начало миграции проекта и команды на начало спринта или инкремента программы, чтобы у вас было некоторое время для адаптации.
Проводите миграцию поэтапно. Импортируйте все данные сразу за выходные, а затем дайте командам время, чтобы постепенно завершить переход на Git. Периодически добавляйте небольшие изменения, повторно запуская инструменты импорта. Хотя это более сложная стратегия, она неплохо подойдет, если у вас есть зависимости между командами, а первым пользователям нужен хотя бы один недавний снимок в Git для подачи в конвейер CI/CD.
В течение некоторого времени используйте обе системы одновременно. Хотя это способ не для слабонервных, технически возможно использовать Git Fusion для двустороннего обмена данными, если вы не выполняете сложных операций, которые могут запутать транслятор данных.

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

Шаг 6. Зеркала и кластеры

Perforce имеет простую, но эффективную систему зеркалирования данных на удаленные площадки, которая позволяет уменьшить влияние задержек. Предусмотрена сложная схема запуска набора локальных зеркал в целях кластеризации только для чтения. Для Git задержка обычно не так уж и важна, но, если вы работаете по всему миру, стоит обратить внимание на возможности кластеризации и зеркалирования в Bitbucket Data Center. Это значительно сократит время клонирования для глобальной команды.

Шаг 7. Инструменты ALM

А теперь хорошие новости: при переходе с Perforce на Git у вас будет большой выбор для стека инструментов ALM. Почти все инструменты разработки и управления жизненным циклом приложения работают с Git, а Bitbucket, естественно, обеспечивает отличную интеграцию с Jira и Bamboo. При переходе на Git изучите функции Bamboo, такие как ветки планов, в которых используются преимущества рабочего процесса с функциональными ветками.

Шаг 8. Определение успешности

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

Гораздо практичнее использовать для проверки CI/CD. Успешно ли проходят все тесты после переключения конвейера CI/CD с Perforce на Git? Можно ли по-прежнему развертывать программное обеспечение? Если все важные старые сборки по-прежнему проходят через конвейер CI/CD, самое время праздновать победу!

Вот и все

Итак, теперь вы понимаете, почему разработчики переходят с Perforce на Git и как это сделать. Следующий шаг — выбор решения Git. Если вы переходите с Perforce и разрабатываете игры, узнайте, за что разработчики игр любят Bitbucket.