Релизная готовность до deploy

Когда использовать

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

Цель не в том, чтобы добавить тяжелый release process. Цель - заранее ответить на вопросы, которые иначе всплывут после выката:

• что именно выпускаем;
• что должно быть принято до релиза;
• как изменение доедет до пользователя;
• как быстро проверить, что production живой;
• куда откатываться, если релиз плохой;
• какой первый сигнал смотреть после публикации.

1. Состав релиза

Перед выкатыванием назовите границу:

• commit, build, версия или набор задач;
• какие страницы, сценарии, API, данные или договоренности затронуты;
• что не входит в релиз, хотя обсуждалось рядом;
• есть ли ручные действия;
• есть ли конфигурация, секреты, домены, права или внешние зависимости;
• кто может подтвердить, что граница названа верно.

Если команда не может назвать состав релиза, она не сможет уверенно понять, что проверять и что откатывать.

2. Приемка до deploy

Проверьте не “все работает”, а конкретные условия:

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

Для контентного релиза это может быть корректный текст, безопасные формулировки, связанные страницы, SEO/discovery-вывод и отсутствие приватных деталей.

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

3. Раскатка

Опишите, как изменение попадет в production:

• кто запускает deploy;
• какой workflow или процедура используется;
• что должно быть зеленым до старта;
• что считается успешным завершением;
• какие действия нельзя делать параллельно;
• кому нужно сообщить о факте выката.

Для маленького статического сайта это может быть:

feature branch -> локальный check -> merge в main -> main CI -> deploy workflow -> production smoke

Для приложения граница будет сложнее: миграции, feature flags, очереди, кэш, фоновые задачи, мониторинг, совместимость старых клиентов.

4. Smoke-check после deploy

Smoke-check не должен повторять весь регресс. Он должен быстро показать, что релиз живет в production.

Минимум:

• ключевая страница или сценарий открывается;
• canonical URL правильный;
• важные маршруты доступны;
• critical assets загружаются;
• публичные discovery-файлы не потерялись, если они важны;
• 404/error behavior не сломан;
• конфигурация production подхватилась;
• аналитика или публичные ссылки работают, если релиз их затрагивал.

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

5. Rollback point

До релиза ответьте:

• какой предыдущий commit, build или состояние считается безопасным;
• как быстро можно его вернуть;
• кто принимает решение об откате;
• какие данные нельзя просто откатить;
• что проверять после отката;
• где записать причину и дальнейшее решение.

Rollback - не признание провала. Это заранее выбранный способ ограничить ущерб.

Если откат невозможен или опасен, это тоже нужно знать до релиза. Тогда команде нужны feature flags, forward-fix, ручной обход, freeze или отдельное решение о риске.

6. Первый сигнал после релиза

Не смешивайте доступность, пользу и дистрибуцию.

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

Шаблон release readiness

## Что выпускаем

Изменение:
Граница релиза:
Что не входит:
Владелец результата:

## Приемка

Главный сценарий:
Критичные ошибки или исключения:
Известные ограничения:
Оставшийся риск:
Кто принял:

## Раскатка

Как выкатываем:
Что должно быть зеленым до deploy:
Что считаем успешным deploy:
Кому сообщаем:

## Smoke-check

Проверяем сразу после deploy:
Где проверяем:
Кто проверяет:

## Rollback

Безопасная точка:
Как откатываем:
Кто принимает решение:
Что проверяем после отката:

## После релиза

Главный сигнал:
Диагностические сигналы:
Когда возвращаемся к результату:
Какое решение нужно записать:

Антипаттерны

Стоит остановиться, если:

• состав релиза описан словами “там несколько правок”;
• приемка сводится к “посмотреть глазами”;
• smoke-check не назван до deploy;
• rollback point появляется только после проблемы;
• команда смотрит на просмотры, когда нужно смотреть на полезное действие;
• первые слабые данные объявляются провалом без периода наблюдения;
• релиз меняет аналитику или приватность, но публичное описание не обновлено.

Короткий итог

Релизная готовность - это короткая договоренность о результате, проверке, последствиях и праве остановиться.

Чем раньше команда отвечает на эти вопросы, тем меньше ей приходится импровизировать на production.