Вливание кода напрямую в trunk

Некоторые команды предпочитают вливать код прямо в trunk. Скорее всего, это небольшая команда и каждый знает чем занимаются другие. Скорей всего, полная сборка проекта у такой команды очень быстрая, и эта команда редко ломает сборку. Если сборка вдруг сломалась (после вливания кода в trunk/master), то такая команда, скорей всего, сразу же откатит этот код и заблокирует trunk для вливания кода на короткий период времени, пока выполняется откат кода. Если команда действительно мала (скажем, три или четыре разработчика), в этом случае кто-то из команды быстро поправит сборку и вольет изменения в trunk, чтобы сборка снова стала стабильной.

В 2000-х годах многие команды разработчиков, которые работали по Trunk-Based Development, насчитывали до 100 коммиттеров. Они могли быть чрезвычайно быстрыми со своими «откатами» (заблокировать trunk, откатить изменения, снова запустить демон CI, разблокировать trunk когда сборка снова станет стабильной). Если бы не было сервера автоматизации сборки, они бы сделали проверки, по которым можно было бы распознать команду C3 1997 года - эта команда хотела лично удостовериться в том, что закрытые проверки - это все, что нужно для сохранения стабильности сборки. Закрытая проверка - это когдав команде есть разработчики, которые говорят «Я/мы сейчас проверяем сборку, не мешайте нам». Они запускают полную сборку всего проекта после того, как обновили код до последней версии, и вливают свой код в trunk если со сборкой все в порядке. Эта церемония является ключевой частью развития Continuous Integration и теперь является частью Agile в целом и экстремального программирования в частности. В наши дни, команды, которые следуют этой практике, вероятно, будут намного меньше по составу участников (скажем, менее 16 разработчиков) из-за появления альтернатив (см.ниже). Тем не менее, все еще есть несколько больших команд, которые так работают.

Преимущества

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

Сложности

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

Риск сломать сборку таким образом снижается если каждый участник команды полностью прогоняет сборку (это также можно поручить CI) перед тем, как влить свой код в trunk, и вливает свой код только если сборка стабильная и тесты проходят. Это и есть основа непрерывной интеграции. Это привычка команд конца 90-х, практикующих экстремальное программирование, и эта практика до сих пор актуальна и эффективна для любой современной команды разработки. Это действительно очень крутая практика во ВСЕХ моделях ветвления.

Если основная ветка заблокирована по требованию команды, то возникает другая сложность - сохранить скорость сборки. Допустим, быстрая сборка длится 1 минуту, а долгая - 10 минут и больше. Компиляция и чистые unit тесты (без потоков, сокетов или чтения/записи файла) - вот то место, где разработке следует сконцентрировать свои усилия для улучшения сборки. Любой «интеграционный тест» на дальнейших этапах сборки, который использует потоки, прослушивает сокеты или выполняет значительный файловый ввод-вывод, должен быть минимизирован настолько, насколько это возможно, без значительного снижения тестового покрытия. Лучший трюк для этого - преобразовать некоторые интеграционные тесты в чистые модульные тесты, что не всегда легко.

У некоторые команды есть политика откатов для коммитов, которые находятся в trunk/master и CI после прогона кода определяет их как “ломающие сборку”. Это может быть человек, который следит за сборкой и предупреждает команду о блокировке trunk для того, чтобы сделать откат. Или это может делать бот в автоматическом режиме, как это делается внутри Google (35 тысяч разработчиков, которые отправляют свой код в trunk).

У некоторых команд есть скрипты, которые гарантируют что разработчики забирают из облачного репозитория на свои рабочие станции только те коммиты, который CI пометил как стабильные и прошедшие тесты. Это может быть так же просто, как и хранить ID коммита (номер или хеш в зависимости от вашей системы контроля версий) где-нибудь на веб-странице, и написание скрипта-обертки для git-pull (или svn up), которая игнорирует более поздние коммиты. Отправка кода обратно в облачный репозиторий становится более сложной с таким подходом к работе, поскрольку она требует чтобы вы скачали HEAD revision перед тем, как вы отправите свой код в удаленный репозиторий. Subversion и Perforce не имеют этого ограничения.

Альтернативы для отправки кода прямо в trunk

Есть современная альтернатива, которая позволяет командам разработки расширяться без узких мест в виде проверок или увеличенных рисков в виде сломанных сборок: Short-Lived Feature Branches.

Также есть команды, которые отправляют исправления в систему проверки, наподобие Gerrit и Rietveld, вместо того чтобы отправлять код напрямую в trunk/master. Google были пионерами в этой области с их системой Mondrian в 2006, а Gerrit и Rietveld были созданы позже по образу и подобию этой системы. Phabricator от Facebook это еще одна похожая система, которая появилась позже. Помимо code review, системы автоматизации сборки объективно проверяют корректность предложенных изменений, придавая вам уверенности в том, что последующее вливание кода в trunk/master даст такой же положительный результат, какой позже даст CI инфрастркутура. Важно заметить, что автоматизация, которую вы подключаете к процессу вливания кода в не-trunk ветки (или систему очередей/проверки для правок), сама по себе не является Continuous Integration.

Эти две альтернативы, помимо отправки кода прямо в trunk, сравниваются в стилях и компромиссах.