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

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

Sarah Goff-Dupont Sarah Goff-Dupont

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для команд, которые предпочитают выполнять текущую работу непосредственно в главном потоке кода, релиз из ветки представляется более привлекательным. Если главная ветка, или ствол, развертывается в тестовой среде, то ветки релизов вы развертываете в разделе проиндексированных файлов и в конечном итоге в рабочей среде. Ветки релизов также могут использоваться в рамках подхода Git-flow.

Снимок экрана 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 и инструментах для разработчиков.