Release Manager

Кто это и зачем нужен

Release Manager отвечает за момент выкатки — чтобы изменения дошли до пользователей безопасно и предсказуемо, без сюрпризов на проде. Его миссия — управлять рисками релиза: что входит в релиз, когда и в каком порядке катим, как откатим, если что-то пойдёт не так. Это «диспетчер» между готовым кодом и живыми пользователями.

Боль, которую он закрывает: «выкатили в пятницу — прод лёг, откатить нечем, кто что катил — непонятно». RM превращает релиз из лотереи в управляемую процедуру.

Что ломается без него: релизы хаотичные, регрессии всплывают на проде, нет плана отката, release notes отсутствуют, разные команды катят несогласованно и ломают друг друга.

День из жизни

Утро. Сверяет содержание ближайшего релиза: что готово, что прошло QA, что ещё в риске. Проверяет, что под каждое изменение есть план отката и фиче-флаг где нужно. День. Координирует выкатку: последовательность шагов, окно релиза, кто на дежурстве. Гоняет релиз-чек-лист (миграции БД обратимы? зависимости задеплоены? мониторинг готов?). Принимает решение go/no-go. Вечер. После выкатки следит за метриками и алертами первые часы, готов нажать «откат». Пишет release notes, фиксирует, что прошло хорошо/плохо для следующего раза.

Ключевые навыки

Hard: релизные стратегии (blue-green, canary, фиче-флаги), CI/CD, управление версиями (semver), миграции БД и их обратимость, мониторинг релиза, runbook отката, понимание регрессионного риска. Soft: хладнокровие в момент выкатки, дисциплина чек-листов, координация команд, готовность сказать «no-go», коммуникация в инциденте.

Артефакты, которые пишет

• Release notes — что изменилось для пользователей/команды.
• Релиз-план — содержание, окно, последовательность.
• Чек-лист готовности — go/no-go критерии.
• Runbook отката — пошагово, как вернуть назад. Готовность опирается на Definition of Done из базы; работает в паре с Delivery Manager (план) и DevOps/SRE (инфраструктура выкатки).

Как ИИ/вайб-кодинг усиливает роль

1. Release notes из коммитов. Промт: «Сгенерируй release notes из этих коммитов/PR <вставить>: сгруппируй по «Новое / Исправления / Технические изменения», человеческим языком, отметь breaking changes.»
2. Чек-лист готовности. Промт: «Собери go/no-go чек-лист релиза для веб-сервиса (фронт + бэкенд + БД): миграции, фиче-флаги, мониторинг, откат, коммуникация. Отметь обязательные пункты.»
3. Runbook отката. Промт: «По изменению <описание, есть миграция БД> напиши пошаговый runbook отката: как откатить код, как обратить миграцию, как проверить, что откат успешен.»
4. Оценка релиз-риска. Промт: «Вот список изменений в релизе <…>. Оцени регрессионный риск каждого (низкий/средний/высокий) и предложи, что катить за фиче-флагом/канарейкой.»
5. Пост-релиз сводка. Промт: «По метрикам и алертам за 2 часа после релиза <данные> скажи, стабилен ли релиз и нет ли признаков деградации.»

Путь развития: Junior → Middle → Senior → Lead

• Junior: ведёт релиз-чек-лист и release notes под присмотром, помогает с координацией.
• Middle: самостоятельно управляет релизным циклом одного продукта, владеет стратегиями выкатки и откатом.
• Senior: выстраивает релизный процесс, автоматизирует, координирует мульти-командные релизы, ведёт инциденты выкатки.
• Lead / Head of Release / часто сливается с DevOps-Lead: отвечает за релиз-инженерию и надёжность доставки в целом.

Частые ошибки и как избежать

• Релиз в пятницу вечером. → Окно релиза, когда есть кому реагировать; не перед выходными.
• Нет плана отката. → Откат — обязательный артефакт ДО выкатки; необратимые миграции — отдельная осторожность.
• «Закатим всё разом». → Канарейка/фиче-флаги, постепенный раскат, наблюдение.
• Release notes «потом». → Пиши сразу; пользователи и команда должны знать, что изменилось.
• Go без проверки готовности. → Жёсткий чек-лист go/no-go, право сказать «нет».

Что освоить (мини-программа)

• Концепции: blue-green/canary деплой, фиче-флаги, semver, обратимые миграции, релиз-чек-листы, мониторинг релиза.
• Инструменты: CI/CD (GitHub Actions/GitLab CI), фиче-флаги (LaunchDarkly/Unleash), мониторинг (Grafana/Sentry), системы версий.
• Почитать: «Continuous Delivery» Хамбл/Фарли; материалы Google SRE про релизы; практики trunk-based development.

Зарплатные ориентиры (RU)

• Junior RM: ~130–190 тыс ₽/мес.
• Middle RM: ~190–300 тыс ₽/мес.
• Senior RM: ~300–430 тыс ₽/мес.

  Часто совмещается с DevOps/SRE; зависит от грейда, города и года — проверяй актуальное.

Маппинг на агента Laskoff

Отдельного mapsTo нет: безопасность выкатки в доме обеспечивает house-rule «перед необратимым (миграции/деплой/удаление данных) — сначала бэкап/ветка, потом действие» + детерминированный hooks/guard-dangerous.sh, который блокирует катастрофу ещё до запуска. Готовность изменения подтверждает quest-verifier (verify зелёный + браузер-тест), release notes — часть фазы Deliver.

🤖 Промт-персона

Ты — дисциплинированный Release Manager. Помогаешь мне выкатывать изменения безопасно и предсказуемо. Перед любой выкаткой требуй: содержание релиза, go/no-go чек-лист, план отката (особенно для миграций БД), стратегию раската (канарейка/фиче-флаг для рискованного). Оценивай регрессионный риск каждого изменения. После релиза подсказывай, какие метрики/алерты смотреть первые часы. Готовь release notes человеческим языком с пометкой breaking changes. Имей смелость сказать «no-go», если готовность не доказана. Никаких релизов в пятницу вечером без причины.