Модель ветвления

Axelix разрабатывается открыто, в виде монорепозитория, поэтому понимание того, как развивается кодовая база, объясняет и то, почему релизы выходят именно так, как выходят.

На этой странице описаны используемые нами ветки, то, как изменения попадают в проект, и как это соотносится с релизами, которые вы потребляете.

Trunk

Axelix следует модели разработки на основе trunk (trunk-based development) — с парой осознанных исключений. Есть один главный trunk: ветка master.

  • Когда мы разрабатываем новую фичу или фикс, мы создаём ветку от master.
  • Мы вливаем её обратно в master через Pull Request.

master всегда является источником истины о том, «что такое Axelix прямо сейчас». Минорные и мажорные релизы режутся напрямую из него — путём проставления тега на trunk вида vX.Y.0, например v3.1.0. Патч-версия у такого тега всегда 0.

Патч-релизы же, напротив, режутся тегами из выделенных патч-веток, которые следуют шаблону X.Y.x (подробнее об этом ниже).

Такие теги (созданные как из trunk-а master, так и из патч-ветки) отмечают скоординированный срез всего флота, в котором каждый компонент выходит вместе под этой одной общей версией

Ломающие изменения

Не каждое завершённое изменение вливается сразу. Если изменение несёт ломающие изменения, мы не вливаем его в master в рамках обычного процесса. Вместо этого мы:

  1. Откладываем Pull Request.
  2. Помечаем его меткой breaking-changes.
  3. Вливаем его позже, когда придёт время — как правило, когда начинаем работать в сторону следующей мажорной версии.

Это позволяет master в любой момент оставаться готовым к выпуску минорной или патч-версии, пока ломающая работа ждёт границы мажорного релиза. Это во многом и есть причина, по которой вы можете доверять тому, что новый минор никогда не протащит ломающее изменение незаметно для вас.

Где живёт патч-работа

Фиксы для уже выпущенной минорной линии не выпускаются напрямую из master — к тому моменту, когда фикс понадобится, trunk обычно уже ушёл вперёд и содержит работу, предназначенную для следующего минора. Вместо этого каждая выпущенная минорная линия получает одну долгоживущую патч-ветку, которая живёт рядом с trunk-ом master.

Патч-ветка ответвляется от тега vX.Y.0 этого минора и называется по шаблону X.Y.x — маленький x обозначает всю патч-линию, и, в отличие от тега, от которого она ответвлена, имя ветки не несёт префикс v. Например, патч-линия релиза 1.0.0 — это ветка 1.0.x, ответвлённая от тега v1.0.0 — вы можете посмотреть на неё в репозитории, чтобы увидеть модель в действии.

Как правило, фикс сначала попадает в master (через обычный процесс с Pull Request), а затем бэкпортируется в патч-ветку затронутой линии. Каждый патч-релиз флота — vX.Y.1, vX.Y.2 и так далее — затем режется из этой ветки и, как и любой релиз Axelix, выпускает все компоненты вместе под одной версией (см. одна версия для всех компонентов).

Одна патч-ветка на минорную линию — не на компонент

На каждую выпущенную минорную линию существует ровно одна патч-ветка, общая для всего флота. Патчи для линии 3.1 — независимо от того, затрагивает фикс стартер, плагин или Master — все живут в единственной ветке 3.1.x, ответвлённой от тега v3.1.0. Веток по компонентам нет, потому что нет и релизов по компонентам: флот версионируется и выпускается как единое целое.

Точные шаги по выпуску релиза — housekeeping, установка версии и запуск пайплайна — описаны на странице Релизы.

На этой странице