🛠 Релизный план: как пережить большие релизы без хаоса 🛠

Когда мы говорим о релизах, многие представляют себе выкладку новой версии или запуск большой фичи. Но самые тяжелые и рискованные релизы случаются не тогда, когда мы добавляем новое, а когда меняем старое: реинженирим огромный кусок системы.
В таких случаях даже после месяцев тестирования все равно есть шанс, что что-то поломается. И это норма, а не ошибка команды. Система слишком сложная, да еще и слишком объемная, да еще и легаси, чтобы предусмотреть все.

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

🤔 Что такое релизный план?
Обычно у релиза release-notes:
— что выкатываем (фичи и номера задач),
— план наката (как выкатывать),
— план отката (как возвращаться).

Релизный план — это полный сценарий, который превращает релиз в управляемый процесс.
В нем прописано:
1️⃣ Чеклист подготовки и проверки к началу релиза (предрелизник).
2️⃣ Определен ответственный за релиз.
3️⃣ Есть пошаговый сценарий с таймингами.
4️⃣ Назначена релизная команда и наблюдатели.
5️⃣ Подготовлен план наката и план отката, а еще и планы Б, В и тп.
6️⃣ Сделаны бэкапы.
7️⃣ Прописаны метрики успеха и критерии переходов между этапами плана.
8️⃣ Обозначен план коммуникации на все ситуации: кого, когда и как информируем.

👥 Кто разрабатывает релизный план?
Всегда есть ответственный. Это может быть:
— разработчик или QA-лид, который "курировал" основные изменения;
— техменеджер;
— релиз-инженер, если такая роль выделена.
Задача этого человека — собрать в план все и со всеми все проговорить и согласовать.

🧩 Кто такие "Релизная команда"?
1) DevOps, SRE, мониторинг;
2) разработчики и тестировщики (включая команды, которые "может цепануть");
3) бизнес-участники (саппорт, комплаенс) — если релиз затрагивает клиентов напрямую.
Но это те, кто будут контролировать и весь основной этап релиза. Если релиз много часовой и/или предполагается еще процесс багофикса, то стоит выделить сменные команды.

📊 Метрики и критерии
Ночью (в "запаре") у вас может не быть сил и мозгов, чтобы беспристрастно принимать решения о переходе на следующий этап релиза/откате/эскалации/смене плана на план Б. Поэтому в плане должно быть четко указано:
✅ что значит «шаг успешен»;
👉 какие критерии перехода к плану B;
🚫 когда откатываем релиз.
Если критерии не прописаны, в момент релиза может начаться спор — и будут потеряны драгоценные минуты.
Да, скорее всего, вы не будете соблюдать все критерии, но, как минимум у вас будет базис для принятия решений и чек-листы проверок!

🔍 Что "засунуть" в предрелизник?
Мысль, что релиз начинается задолго до деплоя — не нова! Но, "продолбаться" очень легко и вот то, что обязательно необходимо проверить:
— уведомлены ли все бизнес подразделения;
— а маркетинг? И не запускают ли они в параллель какаую-то внешнюю активность?
— оповещены ли клиенты (стоят ли заглушки)?
— точно ли никто не будет катить и фриз установлен заблаговременно?
— кроме того, что нужны бекапы свежие, еще и нужны люди, кто умеет бекапы быстро разворачивать
— есть ли скрипт у support на период релиза?
— если аффектим нормативно-правовое поле - "подстелена ли соломка" в виде писем в контролирующие органы?
Очевидное: инфра, миграшки, рубильники, продуманные канарейки и каскадинги, заглушки всех мастей...

Релизный план — это не бюрократия. Это инструмент, который позволяет пережить самые сложные и рискованные изменения без паники.
Да, возможно вы счастливчики и вам еще просто не доводилось "катать" подобное. Но, штука в хозяйсвте полезная...

А в ближайшие дни расскажу о любимом подходе мужа: разделении релизов и деплоев!