Меня зовут Саша Назаров, я занимаюсь релиз-менеджментом в RuStore. 

В предыдущей статье мы рассказывали о роли релиз-менеджера в проекте, о том, когда эта роль нужна, а когда нет, и как мы начинали оптимизацию релизного процесса.

Cегодня разовьём тему и поделимся опытом наших следующих шагов в управлении релизами.

Что хотелось улучшить

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

Мы поставили перед собой две основные цели: релизить быстро и максимально автоматизировать ручные действия в релизном цикле. Цели оказались связанными: без автоматизации кардинально ускорить релизы не получалось.

Почему частые релизы — это важно

Почему важно уметь релизить быстро?

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

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

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

А ещё если релизиться часто, то каждый релиз становится меньше. Маленькие релизы устанавливать проще и быстрее. Изменения функциональности в каждом небольшом релизе получаются не такими существенными. Уменьшается риск ошибиться, а если после релиза всё-таки что-то ломается, гораздо проще разобраться в причине.

Независимым продуктам — независимые релизы

Чем больше сервисов входит в релиз, тем дольше релизный цикл. Поэтому мы отделили независимые наборы сервисов в отдельные релизы.

Большие релизы стали поменьше. Зато у нас теперь много маленьких.

А как за всеми этими релизами уследить?

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

Чтобы проще ориентироваться в релизах, сделали календарь.

Большим релизам стали давать запоминающиеся названия — по праздникам в дни отрезок релиз-кандидатов.

Релизный цикл за три дня

Мы постарались сократить длительность релизного цикла организационно: сделали созвоны перед отрезкой релиз-кандидата, объяснили команде, что релизные активности должны быть в приоритете. Это позволило сократить релизный цикл до трёх дней, и мы стали релизиться дважды в неделю. Но дальше только за счёт энтузиазма сокращать релизный цикл уже не получалось.

И мы решили автоматизировать!

Мы выделили три последовательных этапа в нашем релизном цикле:

1. Подготовка релиз-кандидата

2. Регрессионное тестирование

3. Установка в прод

И задались целью кардинально ускорить каждый из этих этапов.

В этой статье пойдёт речь о первом этапе: как мы полностью автоматизировали подготовку релиз-кандидата, готового к тестированию.

Как было раньше

Полдня мы отрезали релизные ветки для всех наших сервисов и устанавливали сервисы в составе релиза на тестовые стенды.

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

А дальше нужно было координировать работу 10-15 человек и убеждаться, что никто не ошибся (спойлер: кто-то ошибся, но вы этого не заметили ? ).

Автоматическая генерация состава релиза

Мы поставили цель делать всё то же самое автоматически.

Основная сложность заключалась в том, как определять список сервисов и задач в релизе.

И вот как мы её решили.

Цепочки релизов

Помните, что у нас стало много маленьких релизов.

Для каждой категории релиза мы организовали автоматические “цепочки”.

Когда мы отрезаем ветку релиз-кандидата, мы переводим релизную задачу в джире в статус Prepare branches. И перевод статуса триггерит создание следующей задачи с инкрементом релизной версии.

(BW-2024.02.0 New => Prepare Branches) => BW-2024.03.0 New

Больше не нужно создавать релизные тикеты руками!

Привязываем задачи к релизам

Каждая категория релиза включает в себя набор сервисов.

Мы сделали маппинг между полем “Категория релиза” в джире и названием сервиса.

При каждом мёрдже в мастер проставляем идентификатор следующего релиза. 

Для этого определяем категорию релиза по нашему маппингу и находим единственную релизную задачу этой категории в статусе New.

fixVersion этой задачи — это как раз то, что нам нужно!

А ещё заполняем поле component в задаче на разработку — пишем туда имя сервиса, в котором были сделаны изменения.

Таким образом за время подготовки к отрезке релиза у нас формируется список задач, сгруппированных по сервисам.

Автоотрезка и автодеплой по расписанию

Чтобы к началу рабочего дня релиз-кандидат был готов к тестированию, мы начинаем его автоматическое формирование в 5 утра.

Скрипт проверяет календарь релизов, и, если находит запланированную отрезку релиз-кандидата на текущую дату, запускает его подготовку.

Для каждого сервиса в составе релиза от мастера создаётся релизная ветка, собирается релизный билд и сразу же деплоится на тестовый стенд.

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

Но и это ещё не всё

Раньше для каждого сервиса ответственный разработчик руками создавал задачу для SRE на установку сервиса и Merge Request в прод.

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

И в каждой задаче  — Merge Request в прод!

И ещё список изменений в сервисе.

Заключение

Ура! Нам удалось полностью автоматизировать подготовку релиз-кандидата!

Мы уменьшили время подготовки релиз-кандидата с 4 часов до получаса-часа.

Помимо этого мы больше не тратим дорогие часы разработчиков на регулярную рутинную работу.

Надеюсь, наш опыт покажется вам интересным или полезным.

А как вы автоматизируете релизы? Расскажите в комментах! ?