Краткий обзор

Дистанция

Предполагая что у нас есть система контроля версий, доступная через интернет, физическую дистанцию можно сократить с помощью аудио и/или видео технологий за счет демонстрации экрана, например. Так что в наши дни глупо беспокоиться об этом.

“Дистанция” Френка это про дистанцию интеграции кода, от кода, который пишут несколько команд (компонентные, модульные, подкоманды), до двоичного кода, который может быть развернут или отправлен. Проблема дистанции в том, что если разрабатывать не в общей ветке, то это может привести к:

• неожиданной поломке после слияния кода
• сложностям при слиянии кода
• невозможности определить что работа была сделана дважды после слияния
• невозможности определить проблемы несовместимости/нежелательные эффекты, которые могут сломать сборку

Trunk-Based Development это модель ветвления, которая сводит эту дистанцию к минимуму.

Что это такое?

Есть много решающих факторов, прежде чем команда разработчиков остановится на разработке на основе магистралей, но вот краткий обзор. практик, если они их используют:

Возможность релиза незавершенной работы

Код при работе по trunk-Based Development всегда находится в состоянии готовности к релизу

Если управляющий менеджер пришел к команде разработки и сказал “Конкурент X выпустил функционал Y, релизимся прямо сейчас с тем что есть”, то наихудшим ответом может быть “Дайте нам один час”. Команда разработки могла быть очень занята запутанными или трудоемкими задачами (которые были частично завершены), но через час они будут в состоянии стабилизировать и вернуть к жизни то, что находится в trunk. Возможно, они смогут сделать это менее чем за час. Однако, правило никогда не ломать сборку и всегда быть готовыми к релизу чтобы технический директор или кто-то из бизнес команды не могли вас удивить внезапными просьбами.

Из какой ветки делать релиз

Ключевое правило, которое облегчает жизнь, звучит так - Trunk-Based Development команды строго либо выпускают релиз из ветки trunk - см. релиз из ветки trunk, либо они делают ветку из ветки trunk конкретно для текущего релиза, см. ветка для релиза. Команды с высокой частотой релиза делают первое, а у кого частота релизов низкая - второе.

Подтягивание изменений / клонирование

Все разработчики в команде, работающие над приложением/сервисом, клонируют и подтягивают изменения из ветки trunk. Они обновляют/подтягивают/синхронизируют изменения много раз в день, понимая что сборка в порядке. Быстрая система контроля версий, которой пользуются разработчики, означает что они выполняют операцию по синхронизации кода за несколко секунд. Сейчас они ежечасно подтягивают код своих товарищей по команде.

Вливание кода

Точно так же, разработчики, которые закончили какую-то часть своей работы (изменили программный код), которая не ломает билд, вливают эту работу в trunk. То, что этот код не ломает текущую сборку, должно быть доказано. Степень детализации написанного кода (сколько раз разработчик вливает свой код в trunk каждый день) может варьироваться, и обычно ее находят опытным путем, но объемы написанного кода перед слиянием обычно невелики.

Каждый разработчик должен запустить сборку, чтобы доказать что его изменения ничего не сломали, до того как он отправит свой куда-нибудь (Github, Gitlab, Bitbucket etc.). Разработчику может понадобиться обновить/подтянуть/синхронизировать код до того, как он отправит его на сервер системы контроля версий, и дополнительно запустить сборку. Конечно, тут существует риск гонки ресурсов, но давайте предположим что в большинстве команд этого не произойдет.

Code Reviews

Разработчику нужно, чтобы его работа была просмотрена и прокомментирована. Некоторые команды считают что код, который был написан при парном программировании, автоматически прошел code review. Другие команды следуют стандартной практике, при которой код передается на code review перед тем, как будет влит в trunk. В современной инфраструктуре, отправка на code review практически всегда означает ветку/fork (механизм работы через Pull Request), которые команда может посмотреть.

(key)

^ иконки, которые похожи на сообщения в чате, представляют собой комментарии на code review

Ветки, которые были отправлены на code review, могут (и даже должны) быть удалены после того, как code review был сделан, то есть они должны иметь короткое время жизни. Это может показаться немного запутанным для команд, которые недавно перешли или планируют перейти на Trunk-Based Development.

Примечание: вы. возможно, захотите сохранить комментарий/одобрение/отклонение, которое является частью code review, для того, чтобы хранить историю и можно было провести аудит, но вам не следует оставлять саму ветку. В частности, нужно чтобы разработчики делали новую ветку и продолжали работу в ней, а не продолжали работать в ветке, слитой после code review.

A safety net

Continuous Integration (CI) daemons are set up to watch the trunk (and the feature ветки с коротким временем жизни, которые используются на code review), и оповещают команду о том, что сборка сломалась, настолько быстро и в полном объеме, насколько это возможно. Какие-то команды блокируют trunk и делают откат изменений, а какие-то дверяют эту операцию CI серверу, чтобы он делал это автоматически.

(key)

Хорошая практика - проверять код до того, как он будет влит в trunk. Ветки с коротким сроком жизни, которые используются при Pull Request, хорошее место для этой проверки.

Обязательства команды разработки

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

Поговорим подробней про ‘Дистанцию’

Проблему ‘дистанции’ можно проиллюстрировать на наглядных примерах:

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

References elsewhere

показать ссылки