Стратегия веток как дисциплина релизов
Как подход команды к ветвлению в системе контроля версий определяет ритм релизов, исправлений и то, кто может что выпускать без ожидания других.
Большинство разговоров о стратегиях ветвления в системах контроля версий остаются внутри инженерной команды. Выбор между gitflow, trunk-based development или чем-то более неформальным воспринимается как предпочтение разработчиков. На практике это напрямую определяет, как быстро бизнес может выпускать изменения, насколько легко исправить проблему в продакшне без выпуска незаконченной работы, и сколько людей нужно скоординировать перед тем, как что-то выйдет в релиз. Скорость релиза - это инфраструктурная тема, а не просто предпочтение разработчиков.
Я начал внимательнее смотреть на эту тему после нескольких проектов, где команда разработки была технически способной, но процесс релизов - хаотичным. Код был нормальным. Модель ветвления - нет.
Что на самом деле контролирует модель ветвления
В простейшем виде модель ветвления отвечает на три вопроса: где в любой момент находится завершённый, готовый к релизу код; как добавляются новые функции, не блокируя друг друга; и как срочное исправление продакшна разворачивается без попутного вытаскивания недоделанных функций.
Ответы определяют операционный ритм команды. Если ответ на последний вопрос - «нам нужно задержать хотфикс, пока мы обходим незаконченные функции», - команде будет плохо каждый раз, когда продакшн нуждается в быстром патче.
Паттерн gitflow и где он уместен
Модель gitflow Винсента Дриссена, получившая широкое распространение около 2010 года и ставшая стандартным ориентиром к 2014-му, разделяет долгоживущие ветки по назначению: main содержит только выпущенный код, develop - интегрированную работу в процессе, feature-ветки - отдельные функции, release-ветки - период подготовки перед релизом. Хотфиксы ответвляются от main и вливаются обратно как в main, так и в develop.
Ценность этой модели в том, что она делает состояние «готово к продакшну» явным и защищённым. В любой момент можно указать на ветку и сказать: «вот что работает в продакшне, ничто другое». Эта ясность важна, когда нужно быстро доставить исправление.
Цена - необходимость дисциплины для поддержания. Команды, которые наполовину принимают gitflow, получают сложность без преимуществ.
Когда проще - лучше
Gitflow хорошо работает для продуктов с версионными, запланированными релизами. Для сервисов, которые деплоятся непрерывно - где цель выпускать в продакшн несколько раз в неделю, - накладные расходы от долгоживущих веток начинают работать против вас. Trunk-based development, где все часто интегрируются в единую основную ветку и деплоятся оттуда, лучше подходит для такого ритма.
Важно, чтобы выбор соответствовал реальному ритму релизов продукта. Я видел команды, принимающие gitflow, потому что он звучит строго, только чтобы обнаружить, что он добавляет церемонию без добавления безопасности: их реальные релизы были непрерывными, а модель предполагала дискретные версии.
Что ломается чаще всего
Самый распространённый сбой, который я вижу, - это не неправильный выбор модели, а неформальная модель, которую никто не записал. Все думают, что следуют одному подходу, но один разработчик создаёт feature-ветку, которая живёт три месяца, другой деплоится напрямую из личной ветки, а тимлид имеет собственное соглашение для release-веток, отличное от того, что делает кто-либо другой.
Такая неформальность нормальна для команды из двух человек. При пяти людях начинаются сюрпризы. При десяти это становится регулярным источником инцидентов в продакшне.
Простой способ оценить текущее положение
Задайте команде прямой вопрос: если прямо сейчас в продакшне критический баг, какова точная последовательность шагов, чтобы задеплоить исправление в ближайшие два часа - без выпуска незаконченной функциональности? Если ответ чёткий и все дают один и тот же ответ, дисциплина релизов, вероятно, в порядке. Если люди смотрят друг на друга или дают разные ответы - работа есть, независимо от того, какую модель ветвления вы примете.