Управление релизами охватывает все этапы продукта — от разработки и тестирования до продакшена. Это самая ответственная роль, которую может взять на себя IT-специалист. Вместе с коллегами из направления QA SimbirSoft рассказали, на что стоит обратить внимание IT-специалисту, стартующему в роли релиз-менеджера или решившему проанализировать процесс релизов на проекте.
Компетенции релиз-менеджера можно разделить на две части с точки зрения инструментов: техническую и работу с документами.
Техническая часть
Это сборка релизной ветки, деплой, настройка, обновление серверов и базы данных.
Более того, подходы к релизам очень часто зависят от архитектуры приложения, размера проектов, а также выбранных GitFlow. Рассмотрим различные технические аспекты, которые напрямую влияют на стратегию релизов.
Монолит VS микросервисы. Одна из специфик монолита заключается в том, что на большом продолжительном проекте в определенный момент команды становятся более изолированы друг от друга, что может привести к появлению багов. Одни специалисты что-то поправили, а у других что-то «отвалилось» (различные версии гайдов на фронте, например, приводят к падению виджетов).
Разделение на микросервисы отчасти решает проблему. Но в этот переходный период нужно максимально осторожно катить релизы, в которых фичи затрагивают не только свой сервис, а монолит в целом. Любые правки в коде могут отразиться на другом разделе, в котором не было изменений. Поэтому до момента полной смены архитектуры на подобные правки стоит обращать особое внимание при тестировании релиза.
CI/CD. На крупных сложных проектах есть простая закономерность: много параллельных сервисов вносят много изменений в develop. Чтобы релизы не были слишком «жирными», лучше увеличить их частоту. Например, ежедневные выкладки в данной ситуации – хорошая практика. Да пребудет с вами CI/CD.
GitFlow. Немного интересных фактов о модели ветвления Git.
Бывает, статусы задач не дают мерджить ветку там, где должны, а где должны НЕ давать мерджить – позволяют.
Ситуация первая: разработчик забыл поменять статус задачи в таск-трекере и смерджил ее в ветку develop после тестирования – такого быть не должно. Все задачи в develop имеют статус «resolved+».
Ситуация вторая: в релизной ветке оказалась задача в некорректном статусе (см. первую ситуацию). Она не даст смерджить релиз в master – срабатывает «защита от дурака», чтобы в master не попадали не протестированные задачи или задачи со статусами «in review» и т.п.
Кроме того, иногда встречаются проекты, в которых GitFlow можно назвать странным. Например, когда релизная ветка создается не от develop, а от master, и в нее переходят изменения из develop. Получается, код сначала дестабилизируется, а потом стабилизируется. Вопрос корректности такой работы остается открытым.
Резюмируя описанное выше, релиз-менеджеру очень важно знать, понимать и соблюдать GitFlow, поскольку это позволит избежать появления «снежных комов» из хотфиксов, багфиксов и релизов. Элементарно: если во время тестирования релиза появляется срочный хотфикс, то при его мердже в master в ветке происходят изменения, которых нет в релизной ветке, и при выкатывании релиза в тот же master возникнет конфликт ревизий. Поэтому важно держать код в актуальном состоянии и не забывать подливать изменения из хотфикса не только в develop, но и в ветку релиза.
Документация и планирование
Регламент релиза. Прежде всего это подробное описание того, как должен происходить деплой на сервер заказчика, в какое время релизиться, что необходимо проверить после релиза, какие пакеты нужно добавлять вручную и любые другие технические нюансы. Регламент очень важно держать в актуальном состоянии и уведомлять об изменениях всех заинтересованных лиц. Хорошо, если после каждого релиза вы будете общаться с DevOps-инженером или разработчиком, чтобы быть в курсе всех деталей и изменений. Стоит помнить, что актуальный регламент релиза должен быть настоящим спасением для снижения bus factor риска. Не забываем добавить туда и пострелизные мероприятия — описание правил по проведению тестирования на продакшене, действия при откатах, правила работы с хот-фиксами.
Примечание к релизу. Подробные Release Notes (примечания к релизу) помогут быстро ориентироваться в разных версиях продукта и понимать, что мы предоставляем пользователям. А грамотная версионность позволит оценить объем выходящего обновления. Ориентироваться в версиях очень важно в случае, если пользователи долго не обновляются, или при срочных откатах на предыдущую версию. Правильная версионность с Release Notes — это отличный инструмент в расследовании о том, с какой версии просочился баг на продакшен.
Планирование выкладок и расписание. Если сегодня релиз, но появилась еще пара хотфиксов, то стоит обратить особое внимание на их приоритет. Критичные и блокирующие задачи выкатываются в первую очередь, но лучше после выкладки релиза. Чтобы успеть докатить до прода все необходимые изменения, следует планировать порядок деплоя, но это уже другая история, потому что на каждом проекте он свой.
Нет ничего лучше расписания! Во-первых, команды знают, когда у них релиз, и могут планировать выкладку фич. Во-вторых, легче удается планировать реализацию больших задач, которые затрагивают большую часть функционала и взаимодействуют с другими командами. Все очень просто.
Один день из жизни релиз-менеджера
Релиз можно сравнить с локомотивом, который несется несмотря ни на что. Для его управления требуется сноровка и множество технических и управленческих навыков. Однако он также разделен на этапы, в которых участвует вся команда. Чтобы еще глубже понять роль релиз-менеджера, рассмотрим весь жизненный цикл релиза.
1. Собираем список задач, которые должны попасть в релиз. Здесь может быть несколько подходов:
Заводим задачу релиза в таск-трекере, смотрим в нем задачи, у которых есть атрибут «номер релиза: {версия}» и добавляем их списком в общую релизную задачу.
Заводим задачу в таск-трекере, а оунеры продуктовых команд оставляют комментарии с задачами, которые должны попасть в релиз. Также в комментариях оставляют всю необходимую дополнительную информацию, например: нужно выполнить определенные действия в админке, добавить конфигурации, обновить шаблоны и т.д.
2. Создаем релизную ветку и вливаем все задачи релиза в нее.
3. Собираем релиз-кандидат для проведения регресса.
4. Меняем статус у всех задач, которые попали в релиз-кандидат.
5. Во время регресса следим за блокерами релиза (баги с высокой критичностью, краши). У каждого бага должен быть ответственный, а если его нет, то назначаем, поскольку пока баг не исправлен, релиза не будет.
6. По мере необходимости при исправлении багов регресса собираем новые релиз-кандидаты, обновляем общую задачу, дополнив списком багов, которые заехали в очередном релиз-кандидате, меняем статус у задач.
7. При сборке релиз-кандидатов следим, чтобы заливали только исправления багов, обнаруженные во время регресса. Никакие новые фичи на этом этапе не вливаются, даже если очень хочется. Так как часть функциональности уже проверена, новая фича может повлиять на многое и придется проводить регресс снова, есть риск не уложиться в дедлайн. Тут могут быть исключения — при согласовании и под ответственность команды.
8. Когда последний релиз-кандидат устраивает команду QA и нет багов, которые блокируют релиз, то собирается релизная сборка (такая же, как последний релиз-кандидат).
9. Прописываем релизноты, загружаем сборку в магазин приложений (для мобилок). Для мобилок могут быть тонкости, например, плавная раскатка версии на пользователей.
10. Сообщаем QA, которые имеют доступ «к бою», чтобы они скачали сборку из магазина приложений (мобилки), либо зашли на «боевой» стенд и провели необходимые проверки.
11. Закрываем все задачи, которые заехали в новой версии.
12. Ветку релиза вливаем в мастер, мастер вливает в develop. В мастере добавляем тег с номером версии.
13. В течение нескольких дней после релиза следим за крашами. Дальше по согласованию с тимлидом решаем, нужен ли хот-фикс.
Важно
Весь процесс необходимо задокументировать, подробно описать все тонкости. Команда на проекте должна ознакомиться с плановым графиком релизов и согласно нему готовить задачи.
Релиз-менеджер на каждом этапе следует следить за сроками, которые не должны быть нарушены. В случаях задержки сроков он проводит анализ и выявляет причины отсрочки, что позволяет в следующем спринте избежать подобного на каждом этапе.
Хороший релиз-менджер всегда думает о пользователях: как воспримут новый релиз, как поймут, что он содержит новые фичи, какие данные увидит пользователь при открытии новой страницы, не попадут ли на сервер тестовые данные. Все это должно быть проверено с привлечением QA-команды. Ведь кто еще, если не мы? :)
Вывод
Роль релиз-менеджера требует достаточно сильной технической подготовленности с точки зрения знаний инструментов, но также многое зависит и от менеджерской закалки. Если в команде нет выделенной роли, то ответственность за релиз распределяется между членами команды. Но главным контролером часто становится QA-специалист — именно так происходит в SimbirSoft. Мы считаем, что лучше формализовать данную роль, обеспечить выделенное пространство для хранения релизной документации и отладить процессы релизов, тогда успешные деплои в срок, а также положительные отзывы клиентов о новых версиях не заставят себя ждать.
Спасибо за внимание! Полезные материалы для QA-специалистов мы также публикуем в наших соцсетях – ВК и Telegram.
