Perforce to Git: Why make the move

Процесс

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

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

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

Только вдумайтесь: на каждую ветку задания, которую вы хотите создать, чтобы опробовать новую функцию, нужно получить разрешение. Без веток заданий вы можете загрузить в главную ветку нестабильный код или проверять код до бесконечности перед коммитом. Вы отказываетесь от эффективного процесса CI/CD в ветках заданий и возможности детально отслеживать текущую работу. В конечном счете продуктивность падает, поскольку разработчики либо продолжают использовать неэффективные рабочие процессы, либо просто начинают параллельно работать с Git и находят способ вручную объединять код в Perforce.

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

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

Популярность и сообщество

Если не брать в расчет коммерческие аналоги, почему решение Git обошло Mercurial и других достойных конкурентов? Конечно, отчасти дело в историческом преимуществе Git. Продукт Git был создан Линусом Торвальдсом для решения проблем с распределенной разработкой ядра Linux и стал стандартным инструментом SCM для Linux, Android, OpenStack и большинства других значимых проектов с открытым исходным кодом. Им пользуются все первоклассные разработчики, а потому менеджеры по найму склонны ожидать, что новичок сможет (и захочет) работать с Git без серьезного обучения.

Вдобавок к этому вы можете обратиться за поддержкой по вопросам Git к активному сообществу разработчиков ПО с открытым исходным кодом. Git стремительно развивается, чтобы решать насущные проблемы: так, в частности, появилась на свет одна из важных новинок — Git LFS. В проекты Git всегда можно добавить свой код, чтобы исправить найденный баг, и вы не скованы сроками дорожной карты, разработанной владельцем продукта, как это бывает с коммерческими решениями. Вам доступен богатый набор клиентских программ Git: несколько мощных графических интерфейсов для компьютеров, интеграция с Windows Explorer, а также плагины для каждой среды IDE и инструмента разработки.

Графические интерфейсы и инструменты разработки

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

But thankfully those days are past. GUIs like Sourcetree offer a point-and-click experience and there are a multitude of shell integrations for Git. Bitbucket provides code review, merge and pull requests, forking, online code browsing, and a plethora of other collaboration tools. Indeed, everyone from data scientists to creative agencies are organizing communities that make use of the open collaboration that Git and Bitbucket make possible.

В чем особенность разработчиков игр?

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

Двоичные файлы

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

Это создает две проблемы для Git.

• Эти файлы нельзя объединить. В качестве решения можно использовать удобный централизованный механизм блокировки, доступный в Perforce. (Однако обратите внимание, что даже в рамках централизованного сервера механизм блокировки работает только в одной ветке, поэтому такая функция сильно ограничивает возможности рабочего процесса.)
• Эти файлы замедляют работу Git по мере увеличения размера репозитория.

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

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

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

Интересно также оценить, как проблема обработки больших файлов будет развиваться в эпоху больших данных. Чтобы протестировать задание, связанное с аналитикой больших данных, вам может понадобиться набор данных размером в несколько терабайт. Забудьте о системах SCM — этот проект протестирован и запущен на файловой системе, совместимой с большими данными. Здесь нужна система CI/CD, с помощью которой можно организовать сложный конвейер с артефактами, находящимися на HDFS или S3. Это подводит нас к следующей теме.

Крупные проекты

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

Однако сейчас это преимущество в значительной степени спорно. Современные системы Git, включая Bitbucket, упрощают управление многомодульными инструментами Git, такими как подмодули и поддеревья. И что еще важнее, на примере крупных проектов вроде Android можно разобраться в том, как управлять сложным проектом с помощью инструментов композиции более высокого уровня. Многие из этих уроков учтены в современных инструментах CI/CD, таких как Bamboo и Bitbucket Pipelines, которые позволяют организовывать сложные рабочие процессы непрерывной интеграции, моделировать зависимости между проектами и управлять артефактами в нескольких проектах.

Эта тенденция во многом следует философии Git (и *nix), согласно которой создаваемый инструмент должен прекрасно справляться с одной задачей. Непрерывная интеграция и непрерывная поставка (CI/CD) — это отдельная практика со специальными инструментами, которые помогают следить за рабочим процессом, предполагающим создание сборки и выпуск релиза. Она также соответствует современным рекомендациям по разработке программного обеспечения, которые направлены на работу с небольшими автономными микросервисами вместо монолитных проектов.

Следующие действия

Специалисты стали чаще переходить с Perforce на Git, поэтому теперь системе Git и современным инструментам CI/CD под силу справиться с самыми большими и сложными задачами по разработке. Следует отметить, что у Perforce даже появился инструмент под названием Git Fusion, с помощью которого можно извлечь часть центрального репозитория Perforce в виде репозитория Git.

Инструмент Git Fusion весьма хорош, однако решение Git трудно разместить в централизованной системе SCM; если вы попытаетесь совместить модели использования, то можете легко испортить представление данных в одной из систем. Если вы не совмещаете модели использования, то вам будет непросто оценить пользу коммерческого централизованного бэкенда в связке с Git. Как можно заметить, тенденция заключается в обратном, поскольку разработчики чаще пытаются разместить несколько оставшихся полезных централизованных SCM в Git.

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