A step-by-step guide to migrating from Perforce to Git
Как мы обсуждали в предыдущей статье, Git сегодня является признанным стандартом для SCM практически в любой сфере цифровой разработки. Но если ваша ценная многолетняя история хранится в Perforce, вы, вероятно, оцениваете, во что вам обойдется переход. В этой статье мы ответим на ваши сомнения и расскажем, как перенести данные в Git. Мы разбили процесс миграции из 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
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
- Устанавливаете Git Fusion.
- Настраиваете правильные представления данных, в том числе структуру ветвления.
- Используете какой-нибудь клиент Git для клонирования из Git Fusion.
- Отправляете свой репозиторий в Bitbucket
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@repo] description = Acme project charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/… … [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/… … Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in Bitbucket.Однако в результате не всегда получается абсолютно точная копия данных Perforce. Некоторые операции Perforce, такие как частичные слияния, просто не имеют эквивалента в Git. Но в целом этот метод позволяет получить большую часть истории без особых усилий.
Следует иметь в виду, что даже если вы храните историю ветвления из устаревшей системы SCM за последние 10 лет, вы не обязаны использовать тот же рабочий процесс. В качестве первого практического шага следует рассмотреть внедрение таких рабочих процессов для функциональных веток, как Git-flow.
Плюсы и минусы
- Требует больше всего работы по настройке и выполнению.
- Сохраняет большую часть истории (позволяет закрыть устаревший сервер Perforce).
- Сохраняет устаревшую модель ветвления в истории.
Способ 2 для переноса данных из Perforce: начать с нуля
Другой вариант — начать все сначала. Забудьте о навороченной истории. Просто извлеките заголовок (конец) каждой ветки в Perforce, соответствующей вашему проекту, и перенесите его в новый пустой репозиторий Git. (Подразумевается, что у вас есть рабочие пространства Perforce, определенные с помощью правильного представления нужных данных.)
Это самый простой и быстрый способ. Какой бы сложной ни была ваша история в Perforce, новый репозиторий Git будет компактным. Есть возможность начать новый рабочий процесс на основе Git без какого-либо багажа.
Главный минус в том, что вам, может быть, захочется сохранить старый сервер Perforce в режиме чтения на случай, если кому-нибудь понадобится по той или иной причине заглянуть в старый код. Это ничего не будет стоить в смысле лицензионных платежей, однако придется в течение какого-то времени поддерживать старый сервер.
**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.Плюсы и минусы
- Быстрота и простота.
- Изменение модели ветвления и рабочего процесса.
- Устаревший сервер Perforce, используемый только для чтения.
Шаг 2. Пользователи и права
Следующая задача после перемещения данных — сопоставление пользователей и прав с новыми проектами Bitbucket. Если для каталога пользователей используется LDAP, вы сэкономите некоторое время. В противном случае вы можете легко извлечь набор пользовательских аккаунтов из Perforce с помощью команды p4 users –o, а затем ввести их в Bitbucket по одному проекту за раз.
Конвертировать права Perforce в соответствующие права Bitbucket бывает сложно, поскольку в Perforce применяются детализированные сложные правила, позволяющие исключить доступ к отдельным файлам. Эта сложная схема прав является одной из причин, по которой на сервере Perforce могут быть задержки: каждая попытка доступа может приводить к тому, что сервер будет выполнять дорогостоящие вычисления на сложной структуре данных.
В большинстве случаев быстрее будет попросить руководителей проектов создать более простой набор прав в Bitbucket на уровне проекта, репозитория и ветки. На самом деле, настройку прав стоит пересмотреть в любом случае, так как Git предлагает множество новых вариантов рабочего процесса. Например, в Perforce у вас может быть ограничение на создание веток, а в Bitbucket достаточно будет ограничить отправку кода в основную ветку.
Шаг 3. Двоичные файлы
Если в Perforce у вас хранились двоичные большие объекты, продумайте, как управлять ими в Git. Можно попробовать Git LFS или просто использовать обычную систему управления артефактами. В любом случае не стоит вслепую отправлять большие двоичные объекты в репозиторий Git.
Шаг 4. Сложные зависимости
A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/git-subtree.
Шаг 5. Структурирование команды во время миграции
Итак, на вашем сервере Perforce находится 100 проектов от 10 команд. У вас есть стратегия и набор инструментов миграции. Осталось запланировать окно обслуживания — и вперед!
Но… все не так просто.
Помните, что смена инструментов SCM затрагивает не только данные, но и разработчиков. У вас есть люди, процессы и расписание — не пытайтесь вскипятить океан за один день. Это слишком рискованно.
Необходимо обдумать план проектов на этапе самой миграции. (Возможно, сейчас самое время попробовать новый рабочий процесс Jira…) Вот несколько вариантов, которые вы можете рассмотреть.
- Переносите команду за командой и проект за проектом. Запланируйте начало миграции проекта и команды на начало спринта или инкремента программы, чтобы у вас было некоторое время для адаптации.
- Проводите миграцию поэтапно. Импортируйте все данные сразу за выходные, а затем дайте командам время, чтобы постепенно завершить переход на Git. Периодически добавляйте небольшие изменения, повторно запуская инструменты импорта. Хотя это более сложная стратегия, она неплохо подойдет, если у вас есть зависимости между командами, а первым пользователям нужен хотя бы один недавний снимок в Git для подачи в конвейер CI/CD.
- В течение некоторого времени используйте обе системы одновременно. Хотя это способ не для слабонервных, технически возможно использовать Git Fusion для двустороннего обмена данными, если вы не выполняете сложных операций, которые могут запутать транслятор данных.
Наконец, не жалейте сил на информирование команды о предстоящих изменениях, мотивации, причинах и необходимых шагах для их выполнения. Выберите команду «раннего внедрения», инженеры которой имеют опыт работы на всех этапах жизненного цикла разработки программного обеспечения, и пусть эта команда станет образцом для других. Найдите чемпионов Git, которые будут помогать коллегам, когда у них возникнут трудности. Внесение небольших, понятных, итеративных изменений поможет успешно провести этот процесс.
Step 6: Mirrors and clusters
Perforce имеет простую, но эффективную систему зеркалирования данных на удаленные площадки, которая позволяет уменьшить влияние задержек. Предусмотрена сложная схема запуска набора локальных зеркал в целях кластеризации только для чтения. Для Git задержка обычно не так уж и важна, но, если вы работаете по всему миру, стоит обратить внимание на возможности кластеризации и зеркалирования в Bitbucket Data Center. Это значительно сократит время клонирования для глобальной команды.
Step 7: ALM tools
А теперь хорошие новости: при переходе с 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.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.
Блог Bitbucket
Образовательные программы DevOps
