Trunk-Based Development с Feature-флагами: что это, как работает и как внедрить в команде с PWS Remote Config

Что такое Trunk-Based Development

Trunk-Based Development (TBD) — это модель, в которой вся команда работает в одной основной ветке (trunk/main), а любые вспомогательные ветки живут часы или 1–2 дня. Суть — маленькие инкременты, непрерывная интеграция и «всегда зелёный» trunk, из которого можно релизиться в любой момент. Базовое описание и практики — на trunkbaseddevelopment.com.

Ключевые идеи

• Один общий поток изменений. Разработчики интегрируются часто, сохраняют контекст и уменьшают стоимость конфликтов.
• Short-lived branches. Любая ветка — краткая остановка по дороге в trunk, а не «параллельная реальность».
• Green trunk. Если trunk «покраснел» (trunk-ветка “сломана”: тесты упали, пайплайн CI/CD показывает ошибки), команда фиксит его немедленно — это приоритет дня.
• Deploy ≠ Release. Выкладывать код и «включать фичу» — разные события; второе управляется конфигурацией/флагами.

Почему это актуально сейчас

• продукты меняются быстрее, чем успевают выходить «тяжёлые релизы»;
• распределённые команды нуждаются в прозрачной интеграции;
• растёт роль «progressive delivery» и обратной связи с прод-аудиторией.

Роль Feature-флагов в TBD

Feature Flags (toggles) — это переключатели, которые позволяют держать незавершённый функционал в trunk, но выключенным для пользователей, пока команда не готова его показать. В результате:

• мы отвязываем деплой от релиза — код в проде есть, но фича спрятана;
• можем делать dark-launch, канареечные раскатки, A/B и «kill-switch» без нового билда;
• ускоряем фидбэк и снижаем цену ошибок.
  Рекомендации и паттерны — в разделе о флагах на trunkbaseddevelopment.com/feature-flags/.

Хорошая «гигиена» флагов включает:

• классификацию (release/ops/experiment/permission),
• owner и TTL (Time to Live) на каждый флаг,
• описание и нейминг по домену (checkout.express.enabled),
• тест-матрицу (минимум ON/OFF в CI),
• регулярную очистку от устаревших флагов.

Как PWS помогает внедрить TBD: Remote Config как базовая инфраструктура фичефлагов

PWS Remote Config — сервис платформы PWS, который даёт:

• централизованное хранение и управление параметрами и фичефлагами для веба и мобайла;
• моментальное применение изменений без релиза — клиенты запрашивают конфиг и переключаются на лету;
• kill-switch для быстрого отключения проблемного модуля;
• изолированные проекты/окружения (staging/prod) для безопасной поэтапной раскатки;
• REST API для автоматизации в CI/CD и внутренних сервисах — см. справочник API.

Что это даёт TBD-команде:

• код мержится в trunk чаще — пользовательские эффекты прячутся за флагами;
• релиз — это включение фичи, а не публикация новой сборки;
• откаты превращаются в переключения (резкое снижение MTTR);
• одна и та же конфигурация управляет поведением сразу нескольких платформ.

Типовой процесс «TBD + Feature Flags + PWS»

1. Правила trunk. Договоритесь, что trunk всегда зелёный; PR-ветки живут ≤ 1–2 дней; CI блокирует мерж при падении тестов. Подробнее о подходе — на trunkbaseddevelopment.com.
2. Заводим флаг заранее. Создаём параметр в PWS Remote Config, даём человеку-владельца и ожидаемую дату снятия.
3. Пишем за флагом. Код постоянно уходит в trunk; пользовательский эффект — только при flag=ON.
4. Интегрируем часто. Маленькие PR, быстрые ревью, проверки ON/OFF в CI.
5. Dark-launch. Включаем фичу для команды/беты в staging.
6. Прогрессивная раскатка. На проде — поэтапно: 1% → 10% → 50% → 100%, следим за метриками и логами.
7. Откат — переключением. Если что-то идёт не так, выключаем флаг (kill-switch), чиним «вперёд» и продолжаем rollout.
8. Уборка долга. После стабилизации — удаляем ветвления в коде и сам флаг.

Архитектура интеграции Remote Config

• Локальные дефолты. Приложение должно безопасно работать при недоступности сети/сервиса.
• Инициализация и обновления. Запрашиваем конфиг при старте и по расписанию/событию; применяем изменения атомарно.
• Разделение окружений. Отдельные проекты в PWS для staging и prod, независимые значения флагов.
• Наблюдаемость. Логируем чтения/включения, связываем их с метриками продукта (конверсия, ошибки, время отклика).
• Автоматизация через API. В пайплайне CI/CD обновляем значения/варианты флагов и фиксируем историю — см. API Remote Config.

Практики безопасной раскатки

• Canary. Включите флаг для малой доли аудитории/рынка, проверьте ключевые метрики.
• Gradual Rollout. Увеличивайте охват ступенями и держите рядом «красную кнопку» (kill-switch).
• Experiment/Treatment. Разные варианты поведения и контента за счёт параметров типа string/json.
• Permission Toggles. Ограничивайте доступ по ролям/группам, чтобы быстрее собирать фидбэк.
  Референсы по паттернам — в разделе Feature Flags.

Антипаттерны (и что делать вместо)

• Долгоживущие ветки. Делите на инкременты, чаще мержите в trunk.
• Общие «командные» фичеветки. Ветки — для одного разработчика/пары; синхронизация — через trunk.
• Флаги без владельцев и сроков. Введите owner и TTL, заведите ежеспринтовую уборку.
• Ручные переключатели в коде. Держите конфигурацию централизованно (PWS), иначе потеряете историю и контроль.
• Смешивание конфигурации и секретов. Флаги — про поведение, секреты — отдельно.

Метрики успеха TBD (ориентиры)

• Deployment Frequency — растёт (релизиться можно хоть каждый день).
• Lead Time for Changes — сокращается (маленькие PR быстрее проходят).
• Change Failure Rate — падает (флаги и поэтапная раскатка снижают риск).
• MTTR — снижается (откат — выключением флага).

План внедрения на 4–6 недель

Недели 1–2

• Опишите правила trunk и SLA на ревью.
• Разверните PWS Remote Config; заведите 2–3 первых флага под ближайшие задачи.
• Настройте базовую тест-матрицу ON/OFF в CI.

Недели 3–4

• Оберните 1–2 фичи «флагами».
• Запустите dark-launch на staging; подготовьте шаги канареечной раскатки.
• Подключите автоматизацию через API Remote Config

Недели 5–6

• Раскатайте на прод в процентах, мониторьте метрики и логи.
• Проведите «санитарный день» по очистке флагов.
• Зафиксируйте процесс в гайдлайне (шаблоны именования, owner, Time to Live, чек-листы).

Частые вопросы

Нужны ли релизные ветки?

Если релизная частота низкая (например, мобильный стор), отрезайте короткую release-ветку ближе к дате, а фиксы берите cherry-pick из trunk. Основа разработки — всё равно trunk. Подробнее — на trunkbaseddevelopment.com.

Как управлять флагами без доступа разработчика в прод?

Разделите роли в PWS, работайте через UI и автоматизацию по API. Разработчики коммитят, а включением/процентами рулит релиз-менеджер/PO.

Что делать, если Remote Config временно недоступен?

Держите безопасные дефолты и кэш последней конфигурации на клиенте. В худшем случае фича остаётся выключенной — это предсказуемо.

Полезные материалы

• Концепция и практики TBD: trunkbaseddevelopment.com
• Паттерны Feature-флагов в TBD: trunkbaseddevelopment.com/feature-flags/
• Введение в PWS Remote Config: наш пост
• Автоматизация и интеграции: API Remote Config
• Обзор платформы: PWS

Итог и следующий шаг

TBD — это дисциплина маленьких поставок и быстрых интеграций. Feature-флаги делают её практичной: отделяют «деплой» от «релиза», уменьшают риск и ускоряют обратную связь. PWS Remote Config даёт готовую инфраструктуру флагов, окружений и автоматизации, чтобы внедрить этот подход без боли.