Успешная непрерывная интеграция с функциональными ветками и Bamboo

Ветвление позволяет без труда выпускать релизы в любой момент, но есть одна загвоздка.

Sepideh Setayeshfar Sepideh Setayeshfar

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

Благодаря Git и Mercurial активное ветвление перешло из области вымышленных подходов в мир практики, что подробно обсуждалось в статье Пять советов по организации репозиториев Git с поддержкой непрерывной интеграции. Тем не менее, несмотря на все преимущества, использование веток в конвейере непрерывной поставки может создать две конкретных проблемы.

Требования

Время:

30 минут

Аудитория:

Если вы только начинаете работу с непрерывным развертыванием и/или Bitbucket Pipelines

Обязательное условие:

Попробовать бесплатно

Дублирование и отклонение конфигурации сборки

  • Когда разработчик создает ветку, на сервере CI необходимо вручную клонировать несколько конфигураций сборки. Поскольку это ручной этап, некоторые разработчики не утруждают себя таким занятием, и, как следствие, при разработке новой возможности тесты не выполняются. Даже когда мы все-таки копируем конфигурации CI для функциональных веток, мы часто делаем небольшие модификации в разных местах. Затем мы клонируем модифицированные конфигурации для нашей следующей функциональной ветки, вносим еще больше модификаций, и в итоге конфигурация сборки отклоняется от первоначальной, из которой она была клонирована, добавляя головной боли администраторам (и приводя к неприятным сюрпризам, когда эта ветка вновь сливается с главной).

Неопределенность состояния интеграции

  • Если не выполняется постоянное слияние изменений из основной ветки (я буду называть ее главной) с нашей веткой и не запускаются тесты, всегда существует неопределенность относительно того, работают наши изменения или нет — по крайней мере до тех пор, пока не будет выполнено слияние нашей ветки с главной веткой. Неизбежно возникнет ситуация, когда изменения не будут работать должным образом, а главная ветка окажется загрязнена неработающим кодом, что ставит под удар весь смысл функциональных веток и CI.

При создании Bamboo обе эти проблемы были проанализированы и решены в виде возможности, которую мы называем ветками плана. Подробное пояснение по этому вопросу приводится ниже. Читайте дальше!

Ветки плана для функциональных веток

Ветка плана — это элемент плана сборки в Bamboo, соответствующий ветке в репозитории. Они наследуют всю конфигурацию, определенную родительским планом, за исключением того, что осуществляется сборка текущей ветки, а не главной. Затем, после успешного выполнения сборки ветки, можно выполнять автоматическое слияние изменений из этой ветки с главной. В качестве альтернативы успешные сборки веток можно развертывать в тестовой среде, используя возможности развертывания Bamboo (подробнее об этом в другой статье).

Как можно заметить на приведенном ниже снимке экрана, наш план под названием «A CI Tests» выполняет сборку не только главной ветки, но и ветки интеграции, а также нескольких веток, относящихся к конкретным задачам Jira (например, BDEV-10045-bump-tomcat-plugin-5-1). В Bamboo легко понять, в каких планах есть ветки, благодаря отображаемым символам ветки.

Снимок экрана: ветки плана на дашбоарде сборки Bamboo

Как настроить это для существующего плана

  • Войдите в систему как пользователь с правами администратора для этого плана.
  • Перейдите на экран конфигурации, щелкнув значок карандаша на дашбоарде Bamboo или вызвав меню actions (действия) на экране результатов сборки.
  • На экране конфигурации щелкните вкладку branches (ветки).

Отсюда можно настроить Bamboo для автоматического обнаружения новых веток в репозитории и создания соответствующей ветки плана. Обратите внимание, что автоматическое обнаружение веток в настоящее время доступно только для репозиториев Git, Mercurial и Subversion. Однако не переживайте, если вы используете другую систему контроля версий, например TFS или Perforce: вы можете создать ветку плана вручную.

Профессиональный совет. Вероятно, вам не стоит делать сборку каждой создаваемой ветки. Если использовать правила наименования, при котором имена всех веток, которые нужно тестировать, начинаются, например, с «feature-*», Bamboo можно настроить на создание веток плана только для веток, имена которых содержат этот префикс. (В таких настройках также можно использовать регулярные выражения.)

Снимок экрана: управление ветками в конфигурации Bamboo

Большинство функциональных веток существуют недолго (максимум 3–4 дня), поэтому можно настроить план так, чтобы ветки и результаты их сборки удалялись из Bamboo после бездействия в течение определенного количества дней. Эту настройку можно отключить отдельно для каждой ветки, которую нужно хранить в течение неопределенного периода времени, после чего ее потребуется удалить вручную. Не беспокойтесь: независимо от того, удаляется ветка плана автоматически или вручную, Bamboo не удалит саму ветку из репозитория. Это решение остается за вами. Так или иначе, явное отключение автоматической очистки для некоторых веток — хорошая идея в ситуациях, когда вам требуется поддерживать «стабильную» ветку вашего проекта в течение длительного времени.

Простая сборка каждой ветки

Мы настоятельно рекомендуем использовать Git, однако ветку плана возможно создать для любой системы контроля версий, поддерживаемой Bamboo. Чтобы создать ветку плана вручную...

  • Перейдите к экрану результатов сборки для своего плана и выберите команду configure plan (настроить план) в меню actions (действия).
  • Щелкните вкладку branches (ветки), а затем кнопку create branch (создать ветку).
  • В случае с Git и Mercurial появится диалоговое окно со списком всех доступных в репозитории веток, для которых в Bamboo еще нет соответствующей ветки плана.
  • Выберите ветку и нажмите create (создать).
  • Пользователям централизованных репозиториев VCS будет предложено лишь ввести название и описание, выбрать ветку (в случае с Subversion это будет URL, ведущий к ветке), а затем нажать кнопку Create (Создать).
Снимок экрана: создание ветки плана

Теперь, если необходимо, можно отключить автоматическую очистку для текущей ветки плана, а в случае репозиториев DVCS — настроить стратегию слияния. Стратегии слияния позволяют Bamboo автоматически выполнять слияние кода между ветками при успешных сборках (подробнее об этом позже). На этом этапе также можно переопределить информацию о репозитории (если вы используете ветки плана с Subversion, вы можете изменить URL-адрес SVN с trunk на branch) либо переопределить переменные сборки. Например, если существует переменная, указывающая, требуется ли развертывание в рабочей среде, можно изменить ее значение для ветки плана.

Снимок экрана: конфигурации веток в Bamboo

Поскольку этапы сборки для сборок родительского плана и веток этого плана работают одинаково, такие настройки, как триггеры и уведомления, будут унаследованы от родительского плана. Однако эти настройки (и не только) можно переопределить в конфигурации каждой ветки плана для каждой конкретной ветки.

Автоматическое слияние веток

Поскольку вы толком не знаете, все ли работает, пока не выполните слияние изменений в главную ветку (или из нее), в Bamboo для этого доступны два автоматических способа в репозиториях системы DVCS. Эти возможности называются Branch updater (Средство обновления веток) и Gatekeeper, и в любой ветке плана можно использовать любой из этих методов. Если используется средство обновления веток, перед выполнением сборки Bamboo выполнит слияние последних изменений из главной ветки в вашу ветку, а при использовании Gatekeeper — выполнит команду checkout master и выполнит слияние изменений вверх из вашей ветки. (Подробнее о выборе модели слияния см. в документации Bamboo.) Затем Bamboo приступит к выполнению сборки.

Скриншот слияния веток

Если сборка прошла успешно и включен параметр Push on success (Отправка при успешном выполнении), будет автоматически сделан коммит слияния, который сразу же отправится в репозиторий. Если используется модель Gatekeeper, подразумевается, что изменения ветки отправляются в главную ветку. Если используется средство обновления веток, функциональная ветка обновляется путем применения к ней изменений, вносимых в главную ветку.

Снимок экрана: подробные сведения о результате интеграции сборки в Bamboo

Вот это — настоящая непрерывная интеграция!

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