Системы управления версиями*
Приветствую,
Поиск по архивам Хабра показал, что о 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
![](https://habrastorage.org/files/ca5/223/d59/ca5223d591bd4e58aca746e97855075b.png)
Любой сабмит в репозиторий однозначно определяется пронумерованным значением changelist. Changelist должен включать в себя изменения по крайней мере одного файла, а может включать изменения в тысячах файлов. Тут обеспечивается транзакционность, поэтому если в ходе выполнения отправки изменений 10 файлов прервётся соединение между p4d и клиентом, то ни одно из изменений не попадёт в репозиторий. Текущая версия каждого файла также пронумерована и инкрементируется после каждого изменения.
![](https://habrastorage.org/files/486/20c/85e/48620c85e4ca454bbe351f1441d1a6c0.png)
Если хочется перед сабмитом отправить изменения на ревью, то можно воспользоваться функцией shelving, позволяющей отправить копии измененных файлов во временный расшаренный репозиторий («полка» от shelve).
Streams
Стримы – это ветки в Helix, отличие в том, что модель стримов включает сведения о возможности и последовательности действий при работе с ними.
Когда вы создаете стрим, то определяете его тип, ассоциированные файлы и родительский стрим. Когда вы переключаетесь между стримами, срез вашего воркспейса автоматически меняется.
Давайте взглянем на привычную модель ветвления, но отобразим на ней логику работы с ветками:
![](https://habrastorage.org/files/683/3a9/07c/6833a907c7ce486ea493e2b6b2cd5bcf.png)
Допустим была создана ветка для разработки фичи (Project Y). После того как она была успешно разработана и протестирована, фичу хочется заимплементить в проект. Но за время разработки фичи Mainline (master-ветка) изменилась, поэтому перед слиянием требуется убедиться, что Project Y отвечает текущим изменениям в Mainline, и только после этого мёржить Y с Mainline.
p4v включает в себя удобный инструмент для отображения этой информации:
![](https://habrastorage.org/files/63b/b36/c53/63bb36c538a046d48b4bbd7426e02a57.png)
Более стабильные стримы находятся выше Mainline, нестабильные — ниже.
В терминологии Helix существует 2 типа операций с ветками:
1 — merge down,
2 — copy up.
Основной принцип работы со стримами: перед тем, как добавить изменения, сделанные в менее стабильном стриме B, в более стабильный A (copy up В, А), все изменения в более стабильном стриме A должны быть предварительно добавлены в менее стабильный B (merge down А, В).
![](https://habrastorage.org/files/737/521/8b4/7375218b435f43d682e98daaebe03645.png)
Следующий значок означает, что перед тем как скопировать изменения в родительский стрим, необходимо апдейтнуть его из родительского.
Использование стримов автоматизирует ветвление, но можно использовать привычные всем branches.
Jobs, Labels
Помимо использования changelists и стримов, Helix включает в себя дополнительные методы для организации работы:
1 — Jobs привязаны к changelist и отображают статус работы над багом. Они легко интегрируются со сторонними баг-трекерами и настраиваются администратором: в них могут быть отображены не только создатель и зависимый баг, но также добавлены любые другие поля.
2 — Labels привязаны к ревизиям файлов и позволяют объединять их в группы. Если changelist определяет список файлов в одной ревизии, то labes могут относиться к группе файлов из разных ревизий. Они могут быть полезны, когда файлы хочется объединить в привязке к релизу или успешному билду, отметить критически важные компоненты проекта, и т.д.
![](https://habrastorage.org/files/5db/7f5/a5c/5db7f5a5ce4d4c658056573d87c2bc58.png)
Компоненты и некоторые из фич Helix
Helix – тяжеловесная проприетарная СКВ, созданная специально для масштабных проектов и распределённых команд, поэтому имеет ряд необходимых для этого особенностей и поддерживаемой функциональности.
Гибкие механизмы конфигурирования серверов Helix
Чтобы соответствовать вечным заветам (масштабируемость, отказоустойчивость, производительность) Helix поддерживает различные конфигурации серверов:
— Прокси-сервера используются, когда пропускная способность канала подключения ограничена. Отслеживая частые обращения к отдельным файлам, прокси уменьшает количество обращений напрямую к серверу и балансирует сетевой трафик.
![](https://habrastorage.org/files/980/793/a87/980793a87fe94db099ec81860ebc8c26.png)
— Брокеры-сервера используют политики для клиентов, позволяющие балансировать нагрузку входящих обращений.
— Реплики-сервера зеркалируют наиболее горячие (или все) данные основного сервера.
Тип сервера определяется его конфигурацией и может быть настроен администратором. Благодаря гибкости конфигурирования серверов можно добиться максимальной производительности движка, затачивая его специально под нужды команд. Примером может быть commit-edge архитектура:
![](https://habrastorage.org/files/25f/9e9/e01/25f9e9e0154946d9982e2bbd9cfa847a.png)
— Commit-сервера хранят данные и метаданные проекта
— Edge-сервера являются репликой commit-сервера и копией воркспейсов тех пользователей, которые к ним обращаются. Такие сервера обрабатывают только readonly операции и операции перезаписи только тех файлов, которые находятся в воркспейсах пользователей.
Такая архитектура облегчает нагрузку на центральные commit-сервер, что увеличивает производительность.
Аналитика Insights
Одним из компонентов Helix является инструмент Insights для представления важной информации о состоянии проекта, коде, производительности команд. Insights отображает графическое представление такой информации. Метрики совершенно разные, более того они кастомизируются с помощью API.
![](https://habrastorage.org/files/caf/15a/6b4/caf15a6b42ef49259eeeace1585b06a0.png)
Поддержка централизованного и распределенного подхода, GitSwarm
Helix поддерживает обе парадигмы.
В случае централизованного подхода пользователи работают напрямую с сервером p4d. Срез репозитория в их воркспейсах определяет файлы, с которыми могут работать пользователи.
![](https://habrastorage.org/files/f14/210/48e/f1421048e9df4386ba9221f102369054.png)
Всё привычно и не нуждается в дополнительных комментариях. Также соблюдаются традиционные принципы при распределенном подходе.
![](https://habrastorage.org/files/f33/690/241/f336902418f94254917dfae16ef75d1d.png)
Интересной особенностью Helix является гибридный подход, позволяющих различным пользователям или подключаться напрямую к серверу, или использовать собственные локальные сервера, связываясь с центральным репозиторием через push.
Для разработчиков, которые привыкли Git, но хотят пользоваться преимуществами и фичами p4d (описанными выше), существует компонента GitSwarm, включающая в себя сервис GitFusion, использующий p4d как бекенд, и веб-интерфейс для взаимодействия команд и управления проектами:
![](https://habrastorage.org/files/d6d/00c/aaa/d6d00caaa5534fdbafde8af4b01e1e86.png)
По-моему, это действительно круто, так как переход на другую СКВ всегда болезненный процесс, а Helix позволяет оставаться на всеми любимом git’e, проводя при этом все операции через свой движок.
Резюмируя эту часть
Итак, в этой части был сделан общий обзор компонент системы Helix, приведены определяющие workflow p4d понятия, а также описаны некоторые из фич системы.
Какую основную мысль мне хотелось выразить в этой части: Perforce несёт в себе очень мощный, способный к масштабируемости и отказоустойчивости движок p4d, который легко интегрируется с git workflow, но также готовый и к работе через командную строку p4, клиент p4v или через плагины для IDE. Поэтому если что-то не получается (или сложно) сделать через Git, то можно легко переключаться на p4d, и наоборот.
Так как сама по себе платформа очень функциональная, то в будущем хочется посмотреть на каждый из компонентов в отдельности и подробней описать принципы их работы.
Хочется, чтобы те читатели, которые имели опыт работы с Helix поделились своим впечатлением.
Original source: habrahabr.ru (comments, light).
Читать дальше