Про систему контролю версій 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 відповідає поточним змінам в Магістралі, і тільки після цього мержить Y з Магістралі.

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

image

Більш стабільні стріми знаходяться вище Магістралі, нестабільні — нижче.
У термінології 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 поділилися своїм враженням.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.