Фича-команды (Feature Teams) — это организационный подход, где команды формируются вокруг фичей/продуктов, а не компонентов или технологий.
Branch стратегия
Trunk Based Development (TBD) c короткоживущими ветками: Плюсы:
- Меньше конфликтов при слиянии.
- Быстрая доставка до продакшена.
- Проще делать багфиксы так как 1 ветка.
- Повышается осознанность всей команды: все работают с актуальным кодом.
- Упрощается CI/CD: pipeline почти всегда на свежем коде. Минусы/ограничения:
- Требует зрелого CI (юнит, e2e, линтеры, security и т.д.).
- Требует высокой дисциплины: частые коммиты, green build, фичафлаги.
- Требует стратегий изоляции (структурной или рантайм).
Нужны quality gate(s) перед интеграцией:
- unit tests / integration tests (лучше вторые)
- static code analyzers
- mandatory code review (для всех code owner согласно задетому коду)
У TBD есть недостаток - им сложно пользоваться в случае если над кодовой базой работаю параллельно. Если последовательно, проблемы нет. Для того, чтобы дать возможность работать в TBD с кодовой базой параллельно используются:
- структурный дизайн
- branching by abstraction technique
- api versioning
- фича флаги
Подробнее в TBD and feature isolation.
Процесс
Декомпозиция больших задач на мелкие — мелкие это задачи в среднем 2–4 дня на разработку. Если используются типы “фича, стори, таск”, то самая мелкая единица — таск.
У стори должно быть (must have) бизнес-велью.
У таски может быть (nice to have) бизнес-велью.
У таски должно быть (must have) наблюдаемое поведение.
Наблюдаемое поведение таски должно быть протестировано (must have). Внутренние тесты отдельно не должны поставляться.
У стори должна быть таска на e2e (must have).
Если задача не может быть так декомпозирована, она всё равно может вливаться в master согласно общему ритму (nice to have) — чтобы избежать постоянного отставания фичаветки.
Для удобства фича может быть структурно (отдельный пакет) изолирована. Часть связного кода и тестов может быть продублирована для снижения связности между “старой” и “новой” фичами. Таким образом, удаление старой фичи будет дешёвым — удаление соответствующих пакетов кода и тестов.
Если фича не обратносовместима, она должна быть логически (канареечно например) или конфигурационно (через фичафлаг, параметр) изолирована. Оба состояния должны быть протестированы.