О системе контроля версий 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


    image
    Любой сабмит в репозиторий однозначно определяется пронумерованным значением changelist. Changelist должен включать в себя изменения по крайней мере одного файла, а может включать изменения в тысячах файлов. Тут обеспечивается транзакционность, поэтому если в ходе выполнения отправки изменений 10 файлов прервётся соединение между p4d и клиентом, то ни одно из изменений не попадёт в репозиторий. Текущая версия каждого файла также пронумерована и инкрементируется после каждого изменения.
    image
    Если хочется перед сабмитом отправить изменения на ревью, то можно воспользоваться функцией shelving, позволяющей отправить копии измененных файлов во временный расшаренный репозиторий («полка» от shelve).

    Streams


    Стримы – это ветки в Helix, отличие в том, что модель стримов включает сведения о возможности и последовательности действий при работе с ними.
    Когда вы создаете стрим, то определяете его тип, ассоциированные файлы и родительский стрим. Когда вы переключаетесь между стримами, срез вашего воркспейса автоматически меняется.
    Давайте взглянем на привычную модель ветвления, но отобразим на ней логику работы с ветками:

    image

    Допустим была создана ветка для разработки фичи (Project Y). После того как она была успешно разработана и протестирована, фичу хочется заимплементить в проект. Но за время разработки фичи Mainline (master-ветка) изменилась, поэтому перед слиянием требуется убедиться, что Project Y отвечает текущим изменениям в Mainline, и только после этого мёржить Y с Mainline.

    p4v включает в себя удобный инструмент для отображения этой информации:

    image

    Более стабильные стримы находятся выше Mainline, нестабильные — ниже.
    В терминологии Helix существует 2 типа операций с ветками:
    1 — merge down,
    2 — copy up.

    Основной принцип работы со стримами: перед тем, как добавить изменения, сделанные в менее стабильном стриме B, в более стабильный A (copy up В, А), все изменения в более стабильном стриме A должны быть предварительно добавлены в менее стабильный B (merge down А, В).

    image

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

    Jobs, Labels


    Помимо использования changelists и стримов, Helix включает в себя дополнительные методы для организации работы:
    1 — Jobs привязаны к changelist и отображают статус работы над багом. Они легко интегрируются со сторонними баг-трекерами и настраиваются администратором: в них могут быть отображены не только создатель и зависимый баг, но также добавлены любые другие поля.
    2 — Labels привязаны к ревизиям файлов и позволяют объединять их в группы. Если changelist определяет список файлов в одной ревизии, то labes могут относиться к группе файлов из разных ревизий. Они могут быть полезны, когда файлы хочется объединить в привязке к релизу или успешному билду, отметить критически важные компоненты проекта, и т.д.
    image

    Компоненты и некоторые из фич Helix


    Helix – тяжеловесная проприетарная СКВ, созданная специально для масштабных проектов и распределённых команд, поэтому имеет ряд необходимых для этого особенностей и поддерживаемой функциональности.

    Гибкие механизмы конфигурирования серверов Helix


    Чтобы соответствовать вечным заветам (масштабируемость, отказоустойчивость, производительность) Helix поддерживает различные конфигурации серверов:
    Прокси-сервера используются, когда пропускная способность канала подключения ограничена. Отслеживая частые обращения к отдельным файлам, прокси уменьшает количество обращений напрямую к серверу и балансирует сетевой трафик.

    image

    Брокеры-сервера используют политики для клиентов, позволяющие балансировать нагрузку входящих обращений.
    Реплики-сервера зеркалируют наиболее горячие (или все) данные основного сервера.

    Тип сервера определяется его конфигурацией и может быть настроен администратором. Благодаря гибкости конфигурирования серверов можно добиться максимальной производительности движка, затачивая его специально под нужды команд. Примером может быть commit-edge архитектура:

    image

    — Commit-сервера хранят данные и метаданные проекта
    — Edge-сервера являются репликой commit-сервера и копией воркспейсов тех пользователей, которые к ним обращаются. Такие сервера обрабатывают только readonly операции и операции перезаписи только тех файлов, которые находятся в воркспейсах пользователей.
    Такая архитектура облегчает нагрузку на центральные commit-сервер, что увеличивает производительность.

    Аналитика Insights


    Одним из компонентов Helix является инструмент Insights для представления важной информации о состоянии проекта, коде, производительности команд. Insights отображает графическое представление такой информации. Метрики совершенно разные, более того они кастомизируются с помощью API.

    image

    Поддержка централизованного и распределенного подхода, GitSwarm


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

    image

    Всё привычно и не нуждается в дополнительных комментариях. Также соблюдаются традиционные принципы при распределенном подходе.

    image

    Интересной особенностью Helix является гибридный подход, позволяющих различным пользователям или подключаться напрямую к серверу, или использовать собственные локальные сервера, связываясь с центральным репозиторием через push.

    Для разработчиков, которые привыкли Git, но хотят пользоваться преимуществами и фичами p4d (описанными выше), существует компонента GitSwarm, включающая в себя сервис GitFusion, использующий p4d как бекенд, и веб-интерфейс для взаимодействия команд и управления проектами:

    image

    По-моему, это действительно круто, так как переход на другую СКВ всегда болезненный процесс, а Helix позволяет оставаться на всеми любимом git’e, проводя при этом все операции через свой движок.

    Резюмируя эту часть



    Итак, в этой части был сделан общий обзор компонент системы Helix, приведены определяющие workflow p4d понятия, а также описаны некоторые из фич системы.
    Какую основную мысль мне хотелось выразить в этой части: Perforce несёт в себе очень мощный, способный к масштабируемости и отказоустойчивости движок p4d, который легко интегрируется с git workflow, но также готовый и к работе через командную строку p4, клиент p4v или через плагины для IDE. Поэтому если что-то не получается (или сложно) сделать через Git, то можно легко переключаться на p4d, и наоборот.
    Так как сама по себе платформа очень функциональная, то в будущем хочется посмотреть на каждый из компонентов в отдельности и подробней описать принципы их работы.
    Хочется, чтобы те читатели, которые имели опыт работы с Helix поделились своим впечатлением.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 26

      0
      Как с ревью перед комитом в Perforce?

      Есть ли хуки на клиентской стороне?
        0
        Для ревью перед коммитом файлы можно зашелвить (shelve, я упоминал об этом в статье) и отправить на ревью. Подробнее тут.

        Второй вопрос, честно признаюсь, не понял.
          0
          Второй вопрос, видимо, про возможность расширить функциональность клиента.
          Например, как в TortoiseSVN

            0
            Я понял, спасибо :).

            Есть механизм триггеров, но они исполняются на стороне сервера, не клиента. Это скрипты, которые p4d выполнит перед запросом на какую-то операцию со стороны клиента: коммит, логин, смена пароля, etc.

            Это отдельная тема, могу позже написать об этом статью.
            0
            А есть ли возможность сделать «стек» шелвов, т.е. набор изменений, каждое из которых базируется на предыдущем?
              0
              Пока не могу ответить, надо покопаться в этом направлении.

              Я правильно понял, что вы имеете ввиду, можно ли после того, как зашелвили файлы, редактировать их и снова шелвить?
                0
                Да, так. Это, правда, не самоцель, цель — ревью серии изменений, возможно в перфорсе есть другой идеоматичный способ делать это.
                +1
                Нет, такой возможности нет.
                  0
                  Понятно. Очень не хватает после гита.
                0
                Куда отправить? К сожалению, а может и к счастью приходиться пользоваться p4.
                На счет ревью, оно там есть… чисто для галочки. А теперь появляется простейшая вводная, «коммит можно пропустить только после заапрувленного ревью», и вот тут у перфорса начинаются проблемы. Есть нормальные тулы за космические деньги — Code Collaborator от SmartBear. Или вообще ничего, вот прям совсем ничего. Но для того чтобы сделать хоть какой-то вменяемый триггер, который на change-submit будет проверять ( а что проверять? у нас ведь еще нет коммита, мы только хотим его закоммитить. Или даже мы хотим зашелвить чтобы можно было от-ревьюить. А потом этот шелв нужно закоммитить, но при этом чтобы было закрыто ревью), поверьте это ооочень не тривиальное шаманство. И тем кому приходится с этим иметь дело не очень то рады…

                А что касается хуков, гугл: «git precommit hooks» и все! Все проблемы решены, и даже проблемы с проверкой ревью перед коммитом!

                Я что-то «не очень доволен» этим перфорсом…
                0
                У них есть Helix Swarm. Там ревью перед коммитом вроде бы есть и возможность запретить коммит без ревью тоже есть. Только оно ужасно некачественное. Часто нужно вручную указывать, что коммит уже закоммичен иначе ревью не будет закрыто. Иногда Swarm ошибается и закрывает не то ревью и приходится вручную указывать, что это уже закоммичено, а это — еще нет. Причем такие манипуляции может проделать минимум два модератора, т.к. модератор (администратор тоже) не может одобрять собственные ревью.
                +1
                Я полностью согласен с автором статьи Perforce: Fuck you! Если вы прывыкли работать с GIT/ Svn и другими нормальными системами — ни в коем случае не переходите на Perforce. Сэкономьте себе нервы и время. Работа с этий ограмаднейшей кучей хотелок разработчиков, невнятной политикой и видением/пониманиев сабмитов, мерджев и вообщем то каждо дневных действий — тот еще цирк с бубнами. Очень разочаравался в этой программе. Идея «Я художник я так вижу» очень дастает когда ты привык работать по другому (интуитивно). Все в Perforce не интуитивно :( Я так и не понял — то ли дали задание «сделайте не так как у других», то ли сами разработчики перед этом работали грузчиками, не понятно… Я пищу просто предупреждение — если вы привыкли работать с вменяимами системами (как Git, Svn, etc..) ни в коем случае не переходите на Perforce! Подписываюсь под статьей Perforce: Fuck you
                  0
                  Я, кстати, связывался перед написанием поста с авторами упомянутых мной статей, они не были так категоричны, как вы, и отметили, например, преимущества Helix:
                  — автоматизация мёржа
                  — возможность взаимодействовать напрямую из инструментов, с которыми работает команда (IDE, Photoshop, 3DMax, etc.)
                  + многие писали о системе в комментариях к статье о выборе СКВ, что меня и подтолкнуло к описанию платформы.
                  Мне кажется, если бы такая модель workflow не была жизнеспособной, то Helix не был бы популярен :).

                  Также отмечу, что git не кажется интуитивно понятным человеку, привыкшему работать с SVN, например. Также как чистый p4d кажется вам запутанным. Крутость тут в том, что p4d предоставляет возможность работать в привычной среде (том же git, например), но использовать свой движок.
                    +1
                    Попробуйте mercurial (TortoiseHg) — как git, только полностью интуитивно понятный.
                    0
                    Соглашусь с предыдущим оратором. В свое время довелось достаточно пострадать от перфорса. Сложилось впечатление, что авторы продукта надергали всякого (не всегда лучшего) от других систем, а как все это подружить внутри — не подумали. Работать с ним — мучение. Это совсем не гит, это даже не svn по уровню, да что там даже не TFS или (не будь упомянут к ночи) cvs. Perforce хуже чем VSS — потому, что если функционально они очень близки, то VSS хотя бы вменяемый клиент имел.
                      +1
                      Верно и обратное: если вы привыкли работать с нормальной системой (P4) то переход на марсианскую (Git), или даже SVN доставит вам много боли.
                        +3
                        Отлично работаю с hg и перфорсом. А вот гит ужасен.
                        0
                        Как можно работать с VCS, в которой нужно явно checkout'ить каждый файл перед его редактриованием?
                          0
                          1. Большинство плагинов для IDE автоматически чекаутят файлы.
                          2. Есть изначальные индикаторы редактирования файлов, те файлы, которые редактирует член команды, отмечены голубой галочкой, мои красной, следовательно я и другие видят сразу же в solution explorer'e/p4v файлы, которые правят коллеги, и это удобнo: когда файлы какие-то критические, то это помогает, чтобы не мёржить важные файлы. (что-то похожее есть в tfs, но там не показывает файлы, которые правят другие, только твои)
                            0
                            Уж не знаю кому могут пригодится «индикаторы» в п.2.
                            У нас дело обстояло так: никто не хочет замарачиваться с чекаутом каждого файла — поэтому p4-git с локальным репозиторием либо плагины для авточекаута (но многие работали без IDE) в итоге сам p4 никто «напрямую» не использовал. И все из-за этой очень мешающей «мелочи».
                              0
                              В таком случае можно редактировать все файлы, а потом использовать Reconcile Offline Work для нахождения всех изменений и делать чекаут одним махом.
                                0
                                Кстати, ещё вспомнил, что в настройках workspace есть опция writeall, которая позволяет не чекаутить файлы.
                            0
                            Понравилась визуализация — как-то никто не вставил чтобы сверху release снзу dev, а так в принципе все то же самое. Работа с прокси в принципе интересная фича но так себе. Статистику везде можно собрать. Непонятно, за что деньги платить.
                              0
                                0
                                Вот и 2019 год клонится к концу, а воз Perforce и ныне там. Несколько рабочих дней упорного изучения и многомесячный опыт коллег сидящих рядом показывает, что дешевле использовать Git-P4 или GitSwarm, чем понять сам Р4 с его периодическими потерями изменений и абсолютно неочевидной логикой работы доброй половины команд.
                                  0
                                  Пользуясь Perforce, нужно обязательно делать «Check Out» файла, который хочется изменить. Иначе считается, что файл не изменялся и его можно спокойно перезаписывать. У нас была попытка перехода на Git. К сожалению Git жутко медленный на нашем количестве исходников.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое