Модель ветвления
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 в рамках обычного процесса. Вместо этого мы:
- Откладываем Pull Request.
- Помечаем его меткой
breaking-changes. - Вливаем его позже, когда придёт время — как правило, когда начинаем работать в сторону следующей мажорной версии.
Это позволяет 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, установка версии и запуск пайплайна — описаны на странице Релизы.