Что я проверяю перед каждым деплоем

Однажды я уронил прод в пятницу после обеда. Запушил изменение конфига, которое выглядело нормально на стейджинге, но ссылалось на URL базы разработки в одной переменной окружения.

Положил весь сайт на 40 минут. В пятницу. В 4 часа дня. Телефон не переставал жужжать.

С тех пор у меня есть чеклист. Он не длинный. Но я следую ему каждый раз. Без исключений. Даже если «это всего лишь маленький CSS-фикс».

Чеклист

1. Сделай diff изменений

Перед деплоем я смотрю, что именно уходит. Не то, что, как мне кажется, изменилось — а что реально изменилось.

git diff main...HEAD

Я сравниваю diff с тем, что собирался менять. Если в diff есть что-то неожиданное, я останавливаюсь и выясняю почему.

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

2. Проверь конфиг-файлы

JSON-конфиги — хрупкие штуки. Одна пропущенная запятая ломает всё, а сообщение об ошибке обычно выдаёт что-нибудь бесполезное типа «Unexpected token».

Я вставляю каждый изменённый конфиг-файл в JSON-валидатор перед деплоем. Ловит синтаксические ошибки, которые глаза пропустят в 4 часа дня в пятницу.

3. Проверь переменные окружения

Вот на чём я попался. Стейджинг и прод выглядят одинаково, но переменные окружения разные. URL баз данных, API-ключи, фиче-флаги — любая ошибка может вызвать тихие сбои, которые сложно отследить.

У меня есть список переменных окружения, которые отличаются между средами, и я проверяю каждую. Нудно? Да. Лучше, чем положить прод? Тоже да.

4. Протестируй критический путь

Я не прогоняю весь тест-сьют перед каждым деплоем (для этого есть CI). Но я вручную тестирую критический путь пользователя:

• Может пользователь зарегистрироваться?
• Может залогиниться?
• Может сделать главное, для чего наш продукт?
• Может нам заплатить?

Если что-то из этого ломается, всё остальное неважно.

5. Проверь размеры ассетов

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

Быстрые проверки:

• Ни одно изображение не больше 200KB (если нет веской причины)
• CSS и JS минифицированы
• Новые шрифты не добавились случайно

6. Убедись в плане отката

Могу ли я быстро откатить этот деплой, если что-то пойдёт не так?

Для большинства проектов это git revert и передеплой. Но если деплой включает миграции базы, откат сложнее. Узнай это до деплоя, а не во время инцидента.

Чего нет в моём списке

Заметь, чего нет:

• Прогнать все тесты — этим занимается CI. Если тесты прошли в CI, я им доверяю.
• Код-ревью — уже было до мержа. Не относится к моменту деплоя.
• Обновить документацию — важно, но не блокер для деплоя.

Чеклист деплоя — конкретно про «сломает ли это прод?» Не про качество кода, документацию или процесс. Это тоже важно, но происходит раньше.

Правило пятницы

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

С понедельника по четверг, в рабочие часы. Это моё окно для деплоя. Исключения бывают, но они редкие и осознанные.

---

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