Trunk Based Development: техники и определения

Давайте разберем термины из предыдущего поста

Branch By Abstraction — пожалуй, краеугольный камень TBD. Попробуем объяснить эту технику на единорожках. У нас есть обычная лошадка 🐴, но мы понимаем, что вообще-то нам нужен единорог. 🦄

Справка: единороги отличаются от лошадей рогом, магией и тем, что их тошнит радугой. При этом магия без рога не работает.

Соотвественно, нам нужно добавить к нашей лошадке три фичи, чтобы получился единорожек.

Стандартный вариант. Делаем единорожью ветку в репозитории и начинаем разрабатывать в ней. Понимаем, что единорогу нужен усиленный лоб для крепления рога, докидываем его. Команда, занимающаяся магией, форкается от нашей ветки, потому что у них зависимость на рог. Через месяц наш единорог готов, но сразу смержить его в релизную ветку мы не можем, потому что за это время на лбу лошадке нарисовали звездочку к новому году и она несовместима с усиленным лбом. Единорожья ветка жила слишком долго и разъехалась с основной. Чиним конфликты, пару недель на стабилизацию и наш единорог в продакшене. Упс, его тошнит северным сиянием.

Подход Branch By Abstraction так же подразумевает ветвление функционала, но делается это не сопровождением разного кода в репозитории, а введением уровня абстракции в той же кодовой базе. Берем лошадку и эволюционируем ее. Усиливаем лобик, что позволит быстро прикрутить рог, но не будет заметно для пользователя. Добавляем генератор радуги, который пока не включается. Получается, что мы наращиваем функционал, но он какое-то время находится в отдельной логической, а не физической ветке.

Чтобы обезопасить себя и скрыть от пользователя, что с его поняшкой что-то происходит, можно использовать Feature Toggles — механизм управления фича флагами. Этот именно тот переключатель, который выбирает нужную логическую ветку и включает у пони режим единорога.
Есть готовые решения, такие как LaunchDarkly или Unleash, но можно при желании реализовать их самостоятельно.

Например, если надеть специальную перчатку и потрепать за носик, у лошадки включится режим генерации радуги.🌈 Тестировщик сможет включать для себя режим единорога, а обычный пользователь ничего не заметит. При этом это одна и та же лошадка, любое изменение сразу эволюционирует ее. Получается, что фаза тестирования в стандартном код-тест-деплой-релиз у нас смещается вправо (код-деплой-тест-релиз), поэтому такой подход называется Shift Right.

После контроля качества нового функционала, можно открыть его бета-тестерам, а потом какому-нибудь проценту пользователей, чтобы изучить их реакцию. Можно поэкспериментировать с формой рожек, чтобы понять, какой из них больше нравится (AB тесты в таком подходе работают из коробки). Так как передеплоивать ничего не нужно, наша лошадка всегда может вернуться в предыдущее состояние, просто поменяв конфигурацию.
В этот период у нас получается единорог Шредингера: он и есть и нет, все это управляется конфигурацией. Определение релиза фичи при этом тоже меняется — это момент, когда 100% пользователей получат своего единорожка. 🦄

Каждое эволюционное изменение должно быть небольшим по объему и делаться в короткоживущей ветке (Short Living Feature Branch). Такая ветка живет от силы пару дней, быстро ревьюится и объединяется с основной. Кодревью при этом быстр и несложен из-за небольшого объема изменений.

Любое изменение кода сразу же эволюционирует нашу лошадку (раскатывается на продакшн). Такой подход называется Continuos Deployment, не путать с Continuous Delivery, когда мы просто собираем артефакт, но нигде его не устанавливаем. Страшно?

Нет, страшно — это когда неверная логика попадает на прод через месяц после написания, когда детали уже забылись и поверх нее было внесено много изменений. Обязательное условие Continuous Deployment — это большой процент покрытия автотестами, которые просто не дадут смержить в основную ветку код, ломающий предыдущее поведение. При этом даже если ошибка улетает на прод, ее легко откатить, просто сделав реверс коммит.

#rdclr_backend #rdclr_frontend #product