Что такое магистральная разработка?
Магистральная разработка (Trunk Based Development — TBD) — процесс разработки ПО. Согласно trunkbaseddevelopment.com (отличный источник информации о TBD) он определяется как:
Модель ветвления, в которой разработчики совместно работают над кодом в одной ветви, называемой «стволом». При этом другие ветви имеют короткий срок жизни благодаря использованию документированных методов.
Идея заключается в том, что вместо создания ветви функции для разработки кода, которая затем объединяется с основной ветвью, эта функция разделяется на небольшие части, каждая из которых по окончании работы над ней помещается в главную ветвь.
Другими словами… команда занимается разработкой без использования веток.
Помимо того, что небольшие изменения кода в формате TBD сокращают количество конфликтов слияний (повышая настроение разработчиков), магистральная разработка предоставляет преимущества и в других областях:
Частота развертывания и среднее время восстановления
TBD в сочетании с конвейером CI/CD приводит к тому, что каждый «зеленый» коммит (т.е. полная функциональность кода, проверенная с помощью тестов) развертывается на производстве. Перенос каждого изменения в главную ветку предполагает большую интеграцию и развертывание.
Способность быстро развертывать изменения с помощью TBD и CI/CD также позволяет команде с легкостью «выполнить откат» при обнаружении проблем.
Качество кода и обмен знаниями
Наибольший страх, с которым сталкиваются команды при рассмотрении TBD, заключается в том, что качество кода в базе пострадает, а вероятность ошибок возрастет. На самом деле, TBD приводит к гораздо более устойчивому и качественному коду.
Большинство команд, использующих ветви функций, применяют пул-реквест, с помощью которого другие разработчики могут просматривать и комментировать код.
Отсутствие ветвей функций в TBD также предполагает отсутствие пул-реквестов. Однако это не должно стать проблемой. Большинство команд нуждаются в «принципе 4-х глаз», который гласит, что минимум 2 разработчика должны просмотреть и одобрить код перед отправкой в главную ветку.
Достичь выполнения этого принципа можно с помощью парного программирования. Два разработчика, решающие одну проблему, зачастую справляются лучше, чем те, кто работает в одиночку. Все члены команды обладают разным уровнем опыта и знаний технологического стека и/или системы, которую разрабатывает команда. Совместная работа предоставляет возможность учиться у товарищей по команде в ускоренном темпе.
Командная работа
Парное программирование также является формой командной работы, однако TBD повышает уровень эмпатии всех ее участников.
Если старший разработчик захочет увидеть код, написанный младшим, они могут объединиться, и быстрее, чем они успеют это осознать, младший уже будет писать код, достойный гордости старшего.
Потенциальные трудности
Незаконченные функции
Никто не будет предлагать недоработанные функции, такие как кнопка без функциональности, клиентам на производстве. Чтобы избежать этого, команды могут реализовать переключатели функций, за которыми скрываются незавершенные функции. Если работа над функцией не завершена, флаг функции отключается, а когда последний фрагмент выполнен и готов к выпуску, флаг можно включить (или полностью удалить). При использовании переключателей функций можно также применять A/B-тестирование или «канареечный» релиз.
Тестирование и мониторинг
Магистральная разработка требует наличия сильного набора тестов и качественного мониторинга, чтобы как можно быстрее выявлять ошибки. Чем быстрее цикл обратной связи, тем лучше. Починка сломанного конвейера — приоритет номер один для членов команды, ответственных за его поломку.
Этого можно избежать с помощью внедрения небольших изменений, использования среды разработки, максимально схожей с тестовыми и производственными средами, а также выполнения локальных задач конвейера перед отправкой (например, с помощью git-хуков).
Множество команд уже реализовали магистральную разработку, и ни одна из них не вернулась к более распространенной модели пул-реквестов. Однако не стоит забывать о том, что в ПО, как и в жизни, один подход работает не для всех. Необходимо выбрать именно тот, который наилучшим образом подходит для вашей команды.
Читайте также:
- Agile — враг (хорошего проектирования)?
- Введение в создание веб-компонентов
- 10 API консольных утилит Chrome
Перевод статьи Tylor Borgeson: You don’t need Feature Branches anymore…
