О системе контроля версий Perforce Helix
Приветствую,
Поиск по архивам Хабра показал, что о Perforce Helix почти ничего не писали, а в рунете доступна только обзорная статья про расширение для VS и перевод англоязычной старенькой статьи Dear Perforce: fcuk you. При этом в комментариях к статье, посвящённой используемым системам контроля версий, Perforce часто упоминали, поэтому мне захотелось опубликовать пару обзорных статей по функциональности Perforce Helix, которые возможно кому-то помогли бы разобраться в данной платформе, то есть исключительно для информационной составляющей.
Disclaimer: я не профессиональный разработчик, поэтому не использовал Helix в реальном продукте. Для написания статьи я пользовался документацией , бесплатной версией для 20 пользователей, а также предложил части моих студентов использовать Helix при разработке небольшого open-source проекта. Задача этой и последующих статьей — быть источником информации о платформе, поэтому я надеюсь на ваше участие в комментариях
Perforce, Helix, p4, p4d — можно встретить несколько названий того, чем занимаемся Perforce Software (далее — Perforce) уже больше 20 лет. В этом абзаце хочется зафиксировать статус-кво по наименованию компонентов платформы для управления проектами от Perforce (на сегодняшний день):
p4d (Helix Versioning Engine) — движок от Perforce для управления версиями,
p4 — CLI для работы с p4d,
p4v — GUI-клиент для работы с p4d,
Helix — единая платформа от Perforce, включающая в себя:
1 — компоненты для управления версиями (p4d, p4, p4v, плагины для работы из IDE),
2 — компоненту Helix Swarm для ревью кода,
3 — компоненту Helix Insights для аналитики выполненных работ, состояния проекта, производительности команд, исправления багов.
4 — компоненту GitSwarm, основанную на GitLab и позволяющую работать в привычном git workflow в связке с Swarm и использовать преимущества p4d.
Helix имеет клиент-серверную архитектуру и состоит из:
— Сервера с движком p4d, который обеспечивает работу пользователей с репозиториями (в терминологии Helix это depot) и поддерживает работу БД с информацией о работе с файлами, конфигурацией движка, логами активности пользователей, и т.д.
— p4, p4v, плагины для работы из IDE.
Ниже я упомяну определяющие рабочий процесс Helix понятия: changelist, shelving, streams, jobs, labels.
Changelist, shelving
Любой сабмит в репозиторий однозначно определяется пронумерованным значением changelist. Changelist должен включать в себя изменения по крайней мере одного файла, а может включать изменения в тысячах файлов. Тут обеспечивается транзакционность, поэтому если в ходе выполнения отправки изменений 10 файлов прервётся соединение между p4d и клиентом, то ни одно из изменений не попадёт в репозиторий. Текущая версия каждого файла также пронумерована и инкрементируется после каждого изменения.
Если хочется перед сабмитом отправить изменения на ревью, то можно воспользоваться функцией shelving, позволяющей отправить копии измененных файлов во временный расшаренный репозиторий («полка» от shelve).
Streams
Стримы — это ветки в Helix, отличие в том, что модель стримов включает сведения о возможности и последовательности действий при работе с ними.
Когда вы создаете стрим, то определяете его тип, ассоциированные файлы и родительский стрим. Когда вы переключаетесь между стримами, срез вашего воркспейса автоматически меняется.
Давайте взглянем на привычную модель ветвления, но отобразим на ней логику работы с ветками:
Допустим была создана ветка для разработки фичи (Project Y). После того как она была успешно разработана и протестирована, фичу хочется заимплементить в проект. Но за время разработки фичи Mainline (master-ветка) изменилась, поэтому перед слиянием требуется убедиться, что Project Y отвечает текущим изменениям в Mainline, и только после этого мёржить Y с Mainline.
p4v включает в себя удобный инструмент для отображения этой информации:
Более стабильные стримы находятся выше Mainline, нестабильные — ниже.
В терминологии Helix существует 2 типа операций с ветками:
1 — merge down,
2 — copy up.
Основной принцип работы со стримами: перед тем, как добавить изменения, сделанные в менее стабильном стриме B, в более стабильный A (copy up В, А), все изменения в более стабильном стриме A должны быть предварительно добавлены в менее стабильный B (merge down А, В).
Следующий значок означает, что перед тем как скопировать изменения в родительский стрим, необходимо апдейтнуть его из родительского.
Использование стримов автоматизирует ветвление, но можно использовать привычные всем branches.
Jobs, Labels
Помимо использования changelists и стримов, Helix включает в себя дополнительные методы для организации работы:
1 — Jobs привязаны к changelist и отображают статус работы над багом. Они легко интегрируются со сторонними баг-трекерами и настраиваются администратором: в них могут быть отображены не только создатель и зависимый баг, но также добавлены любые другие поля.
2 — Labels привязаны к ревизиям файлов и позволяют объединять их в группы. Если changelist определяет список файлов в одной ревизии, то labes могут относиться к группе файлов из разных ревизий. Они могут быть полезны, когда файлы хочется объединить в привязке к релизу или успешному билду, отметить критически важные компоненты проекта, и т.д.
Helix — тяжеловесная проприетарная СКВ, созданная специально для масштабных проектов и распределённых команд, поэтому имеет ряд необходимых для этого особенностей и поддерживаемой функциональности.
Гибкие механизмы конфигурирования серверов Helix
Чтобы соответствовать вечным заветам (масштабируемость, отказоустойчивость, производительность) Helix поддерживает различные конфигурации серверов:
— Прокси-сервера используются, когда пропускная способность канала подключения ограничена. Отслеживая частые обращения к отдельным файлам, прокси уменьшает количество обращений напрямую к серверу и балансирует сетевой трафик.
— Брокеры-сервера используют политики для клиентов, позволяющие балансировать нагрузку входящих обращений.
— Реплики-сервера зеркалируют наиболее горячие (или все) данные основного сервера.
Тип сервера определяется его конфигурацией и может быть настроен администратором. Благодаря гибкости конфигурирования серверов можно добиться максимальной производительности движка, затачивая его специально под нужды команд. Примером может быть commit-edge архитектура:
— Commit-сервера хранят данные и метаданные проекта
— Edge-сервера являются репликой commit-сервера и копией воркспейсов тех пользователей, которые к ним обращаются. Такие сервера обрабатывают только readonly операции и операции перезаписи только тех файлов, которые находятся в воркспейсах пользователей.
Такая архитектура облегчает нагрузку на центральные commit-сервер, что увеличивает производительность.
Аналитика Insights
Одним из компонентов Helix является инструмент Insights для представления важной информации о состоянии проекта, коде, производительности команд. Insights отображает графическое представление такой информации. Метрики совершенно разные, более того они кастомизируются с помощью API.
Поддержка централизованного и распределенного подхода, GitSwarm
Helix поддерживает обе парадигмы.
В случае централизованного подхода пользователи работают напрямую с сервером p4d. Срез репозитория в их воркспейсах определяет файлы, с которыми могут работать пользователи.
Всё привычно и не нуждается в дополнительных комментариях. Также соблюдаются традиционные принципы при распределенном подходе.
Интересной особенностью Helix является гибридный подход, позволяющих различным пользователям или подключаться напрямую к серверу, или использовать собственные локальные сервера, связываясь с центральным репозиторием через push.
Для разработчиков, которые привыкли Git, но хотят пользоваться преимуществами и фичами p4d (описанными выше), существует компонента GitSwarm, включающая в себя сервис GitFusion, использующий p4d как бекенд, и веб-интерфейс для взаимодействия команд и управления проектами:
По-моему, это действительно круто, так как переход на другую СКВ всегда болезненный процесс, а Helix позволяет оставаться на всеми любимом git«e, проводя при этом все операции через свой движок.
Итак, в этой части был сделан общий обзор компонент системы Helix, приведены определяющие workflow p4d понятия, а также описаны некоторые из фич системы.
Какую основную мысль мне хотелось выразить в этой части: Perforce несёт в себе очень мощный, способный к масштабируемости и отказоустойчивости движок p4d, который легко интегрируется с git workflow, но также готовый и к работе через командную строку p4, клиент p4v или через плагины для IDE. Поэтому если что-то не получается (или сложно) сделать через Git, то можно легко переключаться на p4d, и наоборот.
Так как сама по себе платформа очень функциональная, то в будущем хочется посмотреть на каждый из компонентов в отдельности и подробней описать принципы их работы.
Хочется, чтобы те читатели, которые имели опыт работы с Helix поделились своим впечатлением.
