Инженерия ПО
Git Flow и стратегии ветвления
В 2010 году Винсент Дриссен опубликовал Git Flow - и статья стала одной из самых цитируемых в разработке ПО. В 2020 году тот же Дриссен добавил к ней примечание: «если вам нужен continuous delivery - Git Flow может быть не лучшим выбором». За 10 лет индустрия эволюционировала от жёстких релизных циклов к непрерывной доставке, и стратегии ветвления изменились вместе с ней.
- **Google monorepo**: 86 терабайт кода в одном репозитории, ~35,000 коммитов в день, все в один trunk. Решает merge hell через автоматизацию, а не через изоляцию в ветках
- **GitHub Flow**: упрощённый workflow - ветка от main, PR, review, merge в main, деплой. GitHub использует его для разработки самого GitHub - несколько деплоев в день
- **Stripe API versioning**: строгое следование SemVer, поддержка старых версий API годами. Позволяет тысячам клиентов обновляться в собственном темпе без экстренных изменений
Git Flow
Git Flow - стратегия ветвления, предложенная Винсентом Дриссеном в 2010 году. Центральные ветки: main (продакшн) и develop (текущая разработка). От develop создаются feature ветки для новых функций. Когда набирается достаточно фич - создаётся release ветка для стабилизации. Hotfixes идут напрямую от main и сливаются обратно в main и develop.
Git Flow хорошо работает для команд с явными версионными релизами - библиотеки, мобильные приложения, enterprise ПО. Плохо работает для SaaS с continuous delivery: слишком много overhead на управление ветками, merge conflicts накапливаются, feature branches живут неделями. Сам Дриссен в 2020 году добавил примечание к оригинальной статье: если ваш продукт требует continuous delivery - рассмотрите trunk-based development.
В Git Flow критический баг найден в продакшне. Откуда создаётся hotfix ветка?
Trunk-Based Development
Trunk-Based Development (TBD) - все разработчики коммитят напрямую в main (trunk) или создают короткоживущие ветки (максимум 1-2 дня). Google, Facebook, Uber используют TBD на кодовой базе с тысячами разработчиков. Исследование DORA (State of DevOps Report) показывает корреляцию TBD с высокой производительностью delivery.
Ключевое требование TBD: CI должен проходить всегда. Если коммит ломает сборку - это экстренная ситуация, разработчик обязан исправить немедленно или откатить. Фичи, не готовые к релизу, прячутся за feature flags, а не в отдельных ветках. Это устраняет merge hell - проблему когда долгоживущие ветки расходятся и слияние становится многодневной операцией.
Разработчик работает над большой фичей (2-3 недели). Как это решается в Trunk-Based Development?
Feature Flags
Feature flag (feature toggle) - условие в коде, которое включает или отключает функциональность без деплоя. Facebook использует тысячи feature flags одновременно. Deployment и release разделяются: код деплоится в прод, но фича недоступна пользователям. Когда флаг включается - release без деплоя.
Типы флагов: Release flags (временные, убираются после полного rollout), Experiment flags (A/B тесты, данные собираются для решения), Ops flags (управление поведением системы без деплоя, например throttling), Permission flags (rollout для определённых пользователей). Риск: флаги накапливаются. Netflix удалил 3000 флагов за один раз. Правило: флаг создаётся с датой удаления, иначе становится technical debt.
Чем деплой (deployment) отличается от релиза (release) при использовании feature flags?
Release Management
Release management - процесс планирования, координации и контроля выпуска ПО. Стратегии деплоя: Blue-Green (два одинаковых окружения, переключение трафика между ними), Canary (постепенный rollout: 1% -> 5% -> 25% -> 100%), Rolling (обновление инстансов по очереди без даунтайма). Выбор стратегии зависит от риска изменений и требований к availability.
Semantic Versioning (SemVer): MAJOR.MINOR.PATCH. MAJOR - breaking changes (API несовместимость), MINOR - новая функциональность без разрушения существующего, PATCH - bug fixes. Stripe следует SemVer строго: версия API в URL (/v1/, /v2/), старые версии поддерживаются годами. Это позволяет клиентам обновляться в своём темпе без экстренных изменений.
Trunk-Based Development работает только для небольших команд - большие команды требуют Git Flow с длинными ветками
Google (86TB кода, тысячи разработчиков) и Facebook используют Trunk-Based Development. Масштаб решается через монорепозиторий, автоматизацию тестирования и feature flags, а не через длинные ветки
Длинные ветки создают merge hell независимо от размера команды. Чем больше команда, тем больше конфликтов при слиянии долгоживущих веток. TBD с хорошей автоматизацией масштабируется лучше
При canary deployment новая версия показывает рост latency p99 с 200ms до 800ms на 5% трафика. Правильные действия?
Ключевые идеи
- **Git Flow**: structured workflow с main/develop/feature/release/hotfix ветками - подходит для versioned releases, избыточен для continuous delivery
- **Trunk-Based Development**: коммиты в main ежедневно, ветки живут максимум 2 дня, незавершённые фичи за feature flags - коррелирует с высокой производительностью delivery
- **Feature Flags**: разделяют deployment (публикация кода) и release (включение для пользователей) - основа для canary rollout и A/B тестирования
Связанные темы
Стратегии ветвления определяют как организован delivery pipeline:
- CI/CD Pipeline — CI является обязательным условием Trunk-Based Development - без автоматических тестов TBD невозможен
- Kanban и Lean — Trunk-based development реализует Lean принцип минимального WIP на уровне Git - ветки как незавершённая работа
Вопросы для размышления
- Git Flow был создан в 2010 году. Какие изменения в индустрии за 15 лет сделали Trunk-Based Development более привлекательным?
- Feature flags решают проблему долгоживущих веток, но создают технический долг если не убирать их вовремя. Как организовать lifecycle флагов?
- Canary vs Blue-Green: в каких ситуациях каждая стратегия деплоя предпочтительнее?