Один день из жизни релиз-менеджера

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

1. Собираем список задач, которые должны попасть в релиз. Здесь может быть несколько подходов:
🔹 Заводим задачу релиза в таск-трекере, смотрим в нем задачи, у которых есть атрибут «номер релиза: {версия}» и добавляем их списком в общую релизную задачу.
🔹 Заводим задачу в таск-трекере, а оунеры продуктовых команд оставляют комментарии с задачами, которые должны попасть в релиз. Также в комментариях оставляют всю необходимую дополнительную информацию, например: нужно выполнить определенные действия в админке, добавить конфигурации, обновить шаблоны и т.д.
2. Создаем релизную ветку и вливаем все задачи релиза в нее.
3. Собираем релиз-кандидат для проведения регресса.
4. Меняем статус у всех задач, которые попали в релиз-кандидат.
5. Во время регресса следим за блокерами релиза (баги с высокой критичностью, краши). У каждого бага должен быть ответственный, а если его нет, то назначаем, поскольку пока баг не исправлен, релиза не будет.
6. По мере необходимости при исправлении багов регресса собираем новые релиз-кандидаты, обновляем общую задачу, дополнив списком багов, которые заехали в очередном релиз-кандидате, меняем статус у задач.
7. При сборке релиз-кандидатов следим, чтобы заливали только исправления багов, обнаруженные во время регресса. Никакие новые фичи на этом этапе не вливаются, даже если очень хочется. Так как часть функциональности уже проверена, новая фича может повлиять на многое и придется проводить регресс снова, есть риск не уложиться в дедлайн. Тут могут быть исключения — при согласовании и под ответственность команды.
8. Когда последний релиз-кандидат устраивает команду QA и нет багов, которые блокируют релиз, то собирается релизная сборка (такая же, как последний релиз-кандидат).
9. Прописываем релизноты, загружаем сборку в магазин приложений (для мобилок). Для мобилок могут быть тонкости, например, плавная раскатка версии на пользователей.
10. Сообщаем QA, которые имеют доступ «к бою», чтобы они скачали сборку из магазина приложений (мобилки), либо зашли на «боевой» стенд и провели необходимые проверки.
11. Закрываем все задачи, которые заехали в новой версии.
12. Ветку релиза вливаем в мастер, мастер вливает в develop. В мастере добавляем тег с номером версии.
13. В течение нескольких дней после релиза следим за крашами. Дальше по согласованию с тимлидом решаем, нужен ли хот-фикс.

Подробнее о технической части и документации процесса управления релизами читайте здесь 😎