Привет! Меня зовут Ксения, я уже больше 7 лет занимаюсь релизами и сейчас работаю релиз-менеджером в RuStore. Сегодня хочу рассказать больше об этой роли, в каких случаях он вам нужен (спойлер, не всегда) и когда её можно переложить на другого сотрудника.
Как-то я столкнулась с классическим вопросом от родителей: «Что ты делаешь на работе?» И я задумалась, как можно легко объяснить это... Разработчик разрабатывает, тестировщик тестирует, а я?
А я дирижер в оркестре — хотя это звучит, как клише, но так и есть. В релизном процессе участвует множество разных команд. Казалось бы разработчики и тестировщики, а кто еще? Кроме команд разработки и тестирования, я каждый день взаимодействую с огромным количеством разных ИТ подразделений, например, с поддержкой, ИБ, DevOps, техническими писателями. Я также общаюсь с маркетингом, менеджерами продукта и т. д. Всех этих людей надо скоординировать, правильно передать информацию, организовать так, чтобы в итоге мелодия (то есть релиз) получилась гармоничной и все отыграли свою партию именно тогда и как нужно.
Приведу небольшую схему своих ежедневных взаимодействий:
Когда нужна эта роль, а когда она бесполезна
Чаще всего релиз-менеджер нужен в сложном и быстро развивающемся продукте, таком как RuStore, где необходимо соблюсти высокое качество разработки.
В своей работе я решаю следующие вопросы:
В первую очередь — это координация: Обеспечение эффективного взаимодействия между разными командами и отделами.
Не обходится без релиз-менеджера и планирование: Определение состава релизов, планирование этапов разработки и контрольных точек.
Конечно нужен контроль процесса: Отслеживание всех необходимых проверок и согласований, а также обеспечение соблюдения графика.
Необходима и автоматизация: Создание и продумывание инструментов для ускорения и упрощения процесса релиза.
Выстраивание коммуникаций: Информирование всех заинтересованных сторон об этапах подготовки и установки релиза.
И последнее, но не по значимости — аудит и оптимизация: Проведение аудита процессов и улучшение слабых мест.
На примере жизненного цикла задачи видно, что моя работа покрывает практически половину цикла.
Что поменялось за год
Как мы начинали
Когда я пришла в RuStore, релизы были 1 раз в неделю. Мы с проджект-менеджерами собирались на встречу для формирования скоупа релиза, уточняли состояние задачи, статусы, список сервисов и прочее, а подготовкой релиза к установке занимались DevOps инженеры.
Почти все делалось вручную и занимало много времени и сил. Схема релизного цикла год назад выглядела примерно так:
Общая схема процесса представляла собой следующий воркфлоу:
Оптимизация
Проект развивался, и структура команд менялась. Так, вместо проджект-менеджеров у нас появилось много фиче-команд, и релизный процесс нужно было пересмотреть.
Подготовку сервисов к релизу мы передали разработчикам — они составляли инструкции, merge request и т. д. Таким образом, DevOps инженеры смогли выделять больше времени настройке автоматизации.
При переходе к фиче-командам пришлось собирать подробную информацию об установке сервисов каждой команды. Мы просили тимлидов заполнять чек-листы с описанием изменений, связях между сервисами, тогглами и прочее.
На общей встрече обсуждали нюансы установки всех доработок, на основании этого я составляла план наката и отката релиза, собирала и уточняла другие детали.
Такой подход отнимал много времени и сил у тим-лидов, у меня и моего коллеги. Понимая, что без автоматизации релизов отказаться от этих встреч не получится, мы параллельно настроили:
автоматическую привязку всех готовых задач к релизу;
автоматический сбор списка устанавливаемых сервисов.
В этот момент перед нами встала другая задача — разработать план по увеличению количества релизов. Для этого необходимо было сократить некоторые этапы, например, тестирование и подготовку к установке.
Как мы этап тестирования релиза сокращали
Пересмотр подходов к тестированию и автотестам — это всё понятно, но причем тут релиз-менеджер?
Нам с коллегой надо было решить проблему установки на тестовые стенды. Ответственные за сервисы вручную проводили отрезку релиз-кандидата и установку, что занимало около 5-6 часов, и мы понимали, что это время полезнее было бы выделить на тестирование. Проблему удалось решить настройкой автоотрезки релизных веток и автоматической установкой их на тестовые стенды. Это позволило сократить время подготовки релиз-кандидата с 6 часов до 1 часа.
Как было до:
Как стало после:
Итак, автоматизация помогла ускорить выпуск релизов и освободила дополнительное время для тестирования. Командам стало проще планировать регрессы и тесты, а релизные встречи мы проводить перестали.
Когда релиз-менеджер не нужен?
В таких быстрорастущих проектах, как RuStore, без релиз-менеджера не обойтись. Но бывают ситуации, когда выделять отдельную роль релиз-менеджера на проекте необязательно:
Проект на этапе стартапа — в нём задействовано не так много сотрудников, и все эффективно общаются между собой.
В команде кто-то не сильно нагружен и может взять на себя дополнительную роль.
На проекте очень высокий уровень и культура разработки, а также автоматизации, но при этом все процессы меняются достаточно редко. Такое тоже бывает.
Управлять релизом может любой человек из команды, который как-либо участвует в подготовке или установке релиза.
Чаще всего это бывает кто-то из тестирования, DevOps или продукт-менеджеров.
Но как только проект начинает разрастаться, стоит задуматься о выделении отдельной роли, ведь она позволит развиваться намного быстрее и качественнее.
А что в итоге?
Релиз-менеджер — не всегда заметная, но очень нужная роль, которая обеспечивает доставку качественного кода до пользователей как можно быстрее.
За этот год я еще больше прокачала свои навыки автоматизации, многие процессы пришлось выстраивать с нуля. Я разобралась в Omicrone (нашей системе управления тогглами), помогла команде перейти от одной структуры управления к другой, адаптировав под это наши релизы без потери их качества и количества. Многое еще предстоит сделать, но это уже совсем другая история.
Мы продолжим рассказывать про процесс управления релизами — в следующей статье расскажем, как делать автоотрезку релизов.