Trunk-Based Development: как мы внедряем разработку на основе главной ветки

В начале 2020 года мы в True Engineering сформулировали стратегию «Общего инжиниринга», в рамках которой мы разрабатываем свою базу подходов и стандартов и унифицируем рабочий процесс. На первом этапе мы разработали универсальные требования к ведению проектов и перевели все команды на работу в трекере Azure DevOps. Также в рамках мы постепенно трансформируем процесс тестирования и внедряем в команды функции Software Developer In Test.

Внедрение методологии разработки Trunk-Based-Development (TBD) – это следующий этап нашей трансформации.

Ключевые составляющие TBD

Все релизы в обязательном порядке выходят в ветке Trunk или Master (по-русски – главной ветке). Разработка новых фич ведется в отдельных, коротко живущих ветках, так называемых фича-бранчах (Feature Branches). Разработчик делает ответвление, пишет код в течение одного-двух дней и возвращает ветку обратно в Master.
Принципиально важно всегда поддерживать работоспособность и стабильность Master-ветки. Здесь на помощь приходят Feature toggles (FT) – специальные переключатели в коде, которые отображают/скрывают элементы решения или приложения. Они встраиваются в код во время разработки, а управление ими происходит через специальный портал. Так мы можем скрыть от пользователя нестабильные и незавершенные функции, пока идет доработка, и это не повлияет на работу приложения в целом.
Автоматическое тестирование и непрерывное Code Review – еще две обязательных компонента TBD. Если все изменения в фича-бранче закончены, их нужно оперативно слить в Master, поэтому проверка кода должна быть приоритетной задачей. Что касается автотестов, то строго говоря, они подходят не для всех задач, и покрывать ими 100% кода не нужно (мы подробно рассказывали об этом в статье про наш опыт внедрения практик SDET). Для каждой конкретной задачи сценарий тестирования прописывается на этапе планирования. Для задач, где автотесты актуальны, код сливается в Master только после их прохождения.

Декомпозиция задач и Short-lived ветки

Все ветки кода, кроме главной, должны иметь короткий срок жизни, максимум – несколько дней. Этого можно добиться за счет мелкой декомпозиции: ветка будет небольшой, если она решает небольшую задачу. Правильная постановка задач на этапе планирования играет очень важную роль, поэтому мы придерживаемся принципа декомпозиции задач INVEST и вводим иерархию задач.

Декомпозиция по INVEST определяет, каким должен быть пользовательский сценарий (user story):

Independent — независимый
Negotiable — написанный понятным языком
Valuable — несущий ценность
Estimable — поддающийся оценке
Small — компактный, не более 40 часов разработки
Testable — тестируемый в широком смысле

Каждую из планируемых задач нужно «прогнать» по всем этим пунктам. Если по результатам выпадает хотя бы один из них, задачу нужно декомпозировать заново.

Иерархия задач

При уменьшении отдельных задач их общее количество возрастает многократно. Правильно расставить приоритеты и не потеряться в этом потоке нам помогает иерархия задач.

Непрерывная поставка и TBD

Конечная цель всех наших внутренних изменений – ускорение и оптимизация стандартных этапов создания IT-решений.

Мы тщательно проанализировали наш процесс разработки и нашли несколько точек потери времени и качества – они могут возникать из-на недоработки на конкретном этапе или из-за проблем между разными этапами.

Недостаточная аналитика и декомпозиция;
Сборка релизов из множества задач;
Регрессионное тестирование;
Длительное ожидание Code Review;
Потери на слияние больших изменений;
Отсутствие обратной связи от потребителей.

Для того, чтобы оптимизировать этот процесс, мы переходим от ручной доставки программного обеспечения к практике так называемой “непрерывной поставки” (Continuous Delivery, CD). Это надежный, контролируемый и максимально автоматизированный процесс с понятными и четко измеряемыми рисками, который:

Учитывает потери на каждом этапе;
Учитывает потери на переходах между этапами;
Может быть собран автоматически на основе метрик трекера.

Как мы внедряем TBD в работу команд

Прежде всего, мы придерживаемся мнения, что внедрение методики TBD имеет смысл только в активно растущих продуктах. Если на данном этапе проекта мы выпускаем по одной правке в месяц и ведем поддержку, TBD не актуально.

В целом, мы не рассматриваем переход на TBD как отдельную задачу, мы стараемся действовать комплексно и включаем в наши проекты несколько платформенных практик сразу – это и переход на единый трекер Azure DevOps, и добавление функций SDET в командах, и внедрение TBD, в том числе.

Наши проекты сейчас находятся на разных стадиях перехода на TBD, от проекта к проекту текущий статус может отличаться достаточно сильно. Но, в любом случае, в каждом из них мы стараемся внедрить важные составляющие CD и TBD, например, правильную декомпозицию задач, написание автотестов и тестирование требований.