Применение развертывания на основе веток в конвейере непрерывной поставки

Один из вопросов, с которым нам необходимо разобраться: непрерывная поставка куда? И откуда — тоже немаловажно.

Sarah Goff-Dupont Sarah Goff-Dupont

Мы часто используем термины, например «конвейер», для описания непрерывного потока кода из репозитория к вашим пользователям. Но если нарисовать его схему на бумаге, этот конвейер будет скорее похож на сеть, особенно если вы применяете рабочий процесс «ветки и слияние» (именно это мы настоятельно рекомендуем).

If you're developing on a branch, it makes sense for that branch to have its own deployment path so changes can be thoroughly tested before merging up to main, or even released straight to customers. Atlassian dev tools support branch deploys quite nicely, as you'll see.

Я начну с трех основных примеров использования такого подхода, а затем опишу возможности интеграции между Jira Software, Bitbucket и Bamboo, позволяющие применить все это на практике.

Аргументы в пользу развертываний на основе веток

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

If you're lucky enough to have multiple test environments available, it's even easier. Likewise with releasing to customers: some teams like to release straight from branches, then merge updates from the branch down to main afterwards.

Автоматический запуск развертывания из функциональной ветки

Использование функциональных веток для пользовательских историй и исправления багов — это отличный способ отправки изменений в репозиторий Bitbucket (с возможностью их непрерывной интеграции). Это помогает в процессе работы оградить остальных членов команды от неработающих сборок и ошибок при тестировании.

If your team prefers to ship from main, you'll likely want to deploy that code to internal environments for exploratory and acceptance testing. This works best when there's a handful of test environments your team can deploy to so nobody has to wait for their turn to use a single, shared environment.

При развертывании веток в Bamboo можно настроить для любой среды триггер развертывания, чтобы автоматически развертывать артефакты, собранные в конкретной ветке, через запланированные интервалы либо после каждой успешной сборки для этой ветки в рамках CI. Можно даже использовать сочетание этих двух видов триггеров.

Снимок экрана среды тестирования

Let’s say you have a single performance testing environment that everyone shares. Throughout the day, deploy main there whenever it builds successfully – for most branch-loving teams, builds of main are usually the result of new work being merged in, so you’d want a gut-check on performance right away.

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

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

Снимок экрана проекта развертывания

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

Выпуск продукта из ветки релиза

For teams that prefer to put work in progress directly on the main code line, releasing from a branch is more appealing. While main or trunk gets deployed to the test environment, release branches are the ones you deploy to staging, and ultimately production. Release branches can be used as part of the Gitflow approach as well.

Снимок экрана Gitflow

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

В Bamboo существует понятие «релизов» — сущностей, которые включают в себя самые свежие артефакты, собранные в конкретной ветке, а также все коммиты, результаты тестирования и задачи Jira, связанные со всеми сборками этой ветки с момента последнего релиза. То есть изнутри релиз представляет собой упакованные артефакты и множество метаданных.

И мы хотим, чтобы все эти ценные интересные данные проходили через конвейер непрерывной поставки вместе с артефактами. Тогда можно будет отслеживать процесс вплоть до первого коммита и пользовательской истории, с которой все началось. (Перефразируя Джефри Чосера, можно сказать: «Все дороги ведут в Jira Software».) В глобальном смысле вы продвигаете через свои среды релиз, а не просто сборку. И вы увидите, что все это отражается в пользовательском интерфейсе Bamboo.

Снимок экрана промежуточных релизов среды Bamboo

Но вернемся к триггерам. Когда развертывания запускаются автоматически, как описано в прошлом примере, Bamboo так же автоматически создает релиз.

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

Когда приходит время перенести релиз в следующую среду, перейдите на экран All deployment projects (Все проекты развертывания), где вы найдете все свои проекты развертывания (внезапно!) и все среды, связанные с каждым из проектов. Нажмите на значок развертывания рядом с целевой средой и, следуя инструкциям мастера предварительного просмотра, выберите вариант развертывания существующего релиза (подробную инструкцию по этому процессу см. по ссылке).

Поставка обновлений для поддерживаемых версий

Если вы не живете в мире SaaS, вам, возможно, приходится осуществлять одновременную поддержку нескольких версий ПО и время от времени поставлять критические фиксы, обновления безопасности для старых версий и т. п. Это приводит к необходимости обслуживания веток стабильных версий в течение очень продолжительного времени, чаще всего годами. Сборки из этих веток, как правило, развертываются в одном общем месте, например на веб‑сайте или во внешнем репозитории, откуда клиенты могут осуществлять загрузку обновлений для используемых ими версий.

Снимок экрана: процесс с несколькими версиями

В случае с этими ветками превратить сборки в релизы проще всего с помощью кнопки Create release (Создать релиз) на экране результатов поставляемой вами сборки. Вы, конечно, можете начать с экрана All deployment projects (Все проекты развертывания), как показано выше. Но поскольку вы фокусируетесь на совершенно определенной сборке, которую хотите поставить (и которая необязательно является самой последней сборкой в данной ветке), мне кажется, если вы начнете с экрана результатов сборки, у вас будет немного больше уверенности: да, это именно та сборка, которую я хочу поставить.

Собираем все это вместе (по одному конвейеру непрерывной поставки за раз)

Развертывание на основе веток является естественным расширением веток плана в Bamboo, которые, в свою очередь, являются естественным расширением той схемы использования веток, которую вы настроили для своей команды в Bitbucket (какой бы она ни была). Это показано в статье и подробно обсуждается по ссылке

Существует несколько моделей с поддержкой CD.

Ваша схема веток должна отражать принципы работы вашей команды

Итак, давайте еще раз перечислим основные компоненты.

  • Задачи Jira — помните, что ключи задач творят чудеса. Включайте их в названия своих веток и в комментарии к коммитам, чтобы все коммиты, сборки и развертывания (и даже запросы pull!) включали ссылку, ведущую обратно к задаче.
  • Ветки. Знаете ли вы, что после подключения Bitbucket к Jira Software в каждой задаче появляется удобная ссылка Create branch (Создать ветку)? И что при нажатии этой ссылки к имени ветки автоматически добавляется ключ задачи? Вот так твердо мы уверены в том, что для каждой задачи, над которой вы работаете, важно создавать отдельную ветку. Попробуйте такой подход в следующем спринте, хотя бы ради спортивного интереса.
  • Ветки плана — Bamboo может автоматически обнаруживать новые ветки в репозиториях Git, Mercurial и Subversion, если вы включите автоматическое управление ветками. К тому времени, когда вы осуществите свой первый коммит, Bamboo уже проведет тестирование соответствующей ветки.
  • Проекты развертываний — этапы «поставки» в вашем конвейере непрерывного развертывания. С каждым проектом развертывания можно связать репозиторий и одну или несколько сред.
  • Среды — среды вашей сети в представлении Bamboo. Каждая среда может ассоциироваться с разными ветками, использовать разные триггеры развертывания и предпринимать различные шаги (называемые заданиями) для осуществления успешного развертывания.
  • Релиз — упакованные артефакты + метаданные. При просмотре релиза в Bamboo вы видите все относящиеся к нему задачи Jira (потому что ключи задач работают волшебным образом), коммиты, результаты тестов и артефакты. Вы можете даже посмотреть, в каких средах он был развернут, и пометить его как подтвержденный, чтобы разрешить релизу дальнейшее продвижение по конвейеру, либо как отклоненный.

Каждый описанный мной пример использования применяется как минимум одной командой разработчиков в Atlassian. Некоторые команды даже комбинируют их. И скажу прямо: переход от одного конвейера непрерывной поставки (или отсутствия такового) к сети конвейеров на основе веток займет больше времени, чем вы ожидаете, и обязательно выявит несколько спорных аспектов в текущих процессах, которые вам придется проработать.

Но это нормально. Просто начните. И расскажите, как получается. Свяжитесь с нами через Twitter (@Atlassian) или подпишитесь на блог Atlassian, чтобы получить еще больше полезной информации об agile, Git и инструментах для разработчиков.