Привет! Меня зовут Ксения, я уже больше 7 лет занимаюсь релизами и сейчас работаю релиз-менеджером в RuStore. Сегодня хочу рассказать больше об этой роли, в каких случаях он вам нужен (спойлер, не всегда) и когда её можно переложить на другого сотрудника. 

Как-то я столкнулась с классическим вопросом от родителей: «Что ты делаешь на работе?» И я задумалась, как можно легко объяснить это... Разработчик разрабатывает, тестировщик тестирует, а я?

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

Приведу небольшую схему своих ежедневных взаимодействий:

Когда нужна эта роль, а когда она бесполезна

Чаще всего релиз-менеджер нужен в сложном и быстро развивающемся продукте, таком как RuStore, где необходимо соблюсти высокое качество разработки.

В своей работе я решаю следующие вопросы: 

• В первую очередь — это координация: Обеспечение эффективного взаимодействия между разными командами и отделами.

• Не обходится без релиз-менеджера и планирование: Определение состава релизов, планирование этапов разработки и контрольных точек.

• Конечно нужен контроль процесса: Отслеживание всех необходимых проверок и согласований, а также обеспечение соблюдения графика.

• Необходима и автоматизация: Создание и продумывание инструментов для ускорения и упрощения процесса релиза.

• Выстраивание коммуникаций: Информирование всех заинтересованных сторон об этапах подготовки и установки релиза.

• И последнее, но не по значимости — аудит и оптимизация: Проведение аудита процессов и улучшение слабых мест.

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

Что поменялось за год 

Как мы начинали 

Когда я пришла в RuStore, релизы были 1 раз в неделю. Мы с проджект-менеджерами собирались на встречу для формирования скоупа релиза, уточняли состояние задачи, статусы, список сервисов и прочее, а подготовкой релиза к установке занимались DevOps инженеры.

Почти все делалось вручную и занимало много времени и сил. Схема релизного цикла год назад выглядела примерно так:

Общая схема процесса представляла собой следующий воркфлоу:

Оптимизация

Проект развивался, и структура команд менялась. Так, вместо проджект-менеджеров у нас появилось много фиче-команд, и релизный процесс нужно было пересмотреть. 

Подготовку сервисов к релизу мы передали разработчикам —  они составляли инструкции, merge request и т. д. Таким образом, DevOps инженеры смогли выделять больше времени настройке автоматизации.

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

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

Такой подход отнимал много времени и сил у тим-лидов, у меня и моего коллеги. Понимая, что без автоматизации релизов отказаться от этих встреч не получится, мы параллельно настроили: 

• автоматическую привязку всех готовых задач к релизу; 

• автоматический сбор списка устанавливаемых сервисов. 

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

Как мы этап тестирования релиза сокращали 

Пересмотр подходов к тестированию и автотестам — это всё понятно, но причем тут релиз-менеджер? 

Нам с коллегой надо было решить проблему установки на тестовые стенды. Ответственные за сервисы вручную проводили отрезку релиз-кандидата и установку, что занимало около 5-6 часов, и мы понимали, что это время полезнее было бы выделить на тестирование. Проблему удалось решить настройкой автоотрезки релизных веток и автоматической установкой их на тестовые стенды. Это позволило сократить время подготовки релиз-кандидата с 6 часов до 1 часа. 

Как было до: 

Как стало после: 

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

Когда релиз-менеджер не нужен?

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

• Проект на этапе стартапа — в нём задействовано не так много сотрудников, и все эффективно общаются между собой.

• В команде кто-то не сильно нагружен и может взять на себя дополнительную роль.

• На проекте очень высокий уровень и культура разработки, а также автоматизации, но при этом все процессы меняются достаточно редко. Такое тоже бывает.

Управлять релизом может любой человек из команды, который как-либо участвует в подготовке или установке релиза. 

Чаще всего это бывает кто-то из тестирования, DevOps или продукт-менеджеров. 

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

А что в итоге?

Релиз-менеджер — не всегда заметная, но очень нужная роль, которая обеспечивает доставку качественного кода до пользователей как можно быстрее. 

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

Мы продолжим рассказывать про процесс управления релизами — в следующей статье расскажем, как делать автоотрезку релизов.