Как проверить, что новая версия действительно работает

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

Это чувство знакомо каждому, но оно же и опасно. Один человек, проверяющий одну страницу — это невоспроизводимый процесс. Он не скажет вам, работают ли другие функции. Он не покажет, корректно ли отвечает API. И уж точно не даст понять, будет ли у пользователей хороший опыт.

Если верификация деплоя полагается на чью-то интуицию, вы по сути используете своих пользователей как первую систему обнаружения проблем. К тому времени, как они сообщат о неисправности, ущерб уже будет нанесён.

Проблема ручных проверок

У ручных проверок после деплоя есть три фундаментальных недостатка.

Первый — непостоянство. Сегодня один человек может проверять одно, завтра другой — совершенно другое. Один проверит страницу логина, другой — поиск. Вы не сможете сравнить результаты разных деплоев, потому что сами проверки постоянно меняются.

Второй — поверхностность. Человек за разумное время способен проверить лишь несколько страниц или эндпоинтов. Сложные сценарии, включающие несколько шагов, после каждого деплоя вручную тестируют редко. А ломаются чаще всего именно те многошаговые процессы, которые никто не проверяет.

Третий — медлительность. К тому моменту, как кто-то закончит проверку пары страниц, деплой уже может обслуживать тысячи пользователей. Если что-то сломалось, эти пользователи уже пострадали.

Здесь на помощь приходит верификация как структурированный процесс. Верификация — это проверка того, что новая версия действительно работает корректно, причём не только со стороны сервера, но и с точки зрения пользователя. Она отвечает на один вопрос: «Могут ли люди использовать эту версию без очевидных проблем?»

Начните со smoke-тестов

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

В терминах деплоя smoke-тест выполняет базовые проверки, чтобы убедиться, что новая версия не сломана сразу. Эти проверки просты и быстры. Они не проверяют бизнес-логику. Они ловят только самые очевидные ошибки.

Типичный smoke-тест может включать:

Вот конкретный пример скрипта smoke-теста, который можно запускать после каждого деплоя:

#!/bin/bash
# smoke-test.sh — базовые проверки после деплоя

BASE_URL="http://localhost:8080"
FAILED=0

check_endpoint() {
  local url="$1"
  local description="$2"
  local status=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  if [ "$status" -eq 200 ]; then
    echo "PASS: $description"
  else
    echo "FAIL: $description (HTTP $status)"
    FAILED=1
  fi
}

check_endpoint "$BASE_URL/" "Главная страница возвращает 200"
check_endpoint "$BASE_URL/login" "Страница логина рендерится"
check_endpoint "$BASE_URL/api/health" "Эндпоинт здоровья отвечает"
check_endpoint "$BASE_URL/static/css/main.css" "CSS-ресурс загружается"

if [ "$FAILED" -eq 1 ]; then
  echo "Smoke-тесты не пройдены. Рекомендуется откат."
  exit 1
else
  echo "Все smoke-тесты пройдены."
fi

• Загрузка главной страницы и подтверждение HTTP 200
• Проверка, что страница логина рендерится без ошибок
• Проверка, что критический эндпоинт API отвечает за разумное время
• Подтверждение, что статические ресурсы (CSS, JavaScript) загружаются корректно

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

Smoke-тесты должны выполняться меньше чем за минуту. Если они занимают больше времени, это уже не smoke-тесты. Держите их быстрыми и поверхностными.

Углубляйтесь с синтетическими транзакциями

Как только smoke-тесты пройдены, можно переходить к более тщательной проверке — синтетическим транзакциям. Это автоматизированные симуляции того, что делают реальные пользователи в вашем приложении.

Синтетическая транзакция — это не просто проверка загрузки страницы. Она проходит через реальный пользовательский сценарий. Например:

1. Открыть главную страницу
2. Нажать кнопку «Войти»
3. Ввести тестовые имя пользователя и пароль
4. Отправить форму логина
5. Перейти к определённой функции
6. Заполнить форму тестовыми данными
7. Отправить форму
8. Проверить, что ожидаемый результат появился на следующей странице

Синтетические транзакции отличаются от smoke-тестов двумя важными аспектами.

Во-первых, они длиннее и реалистичнее. Smoke-тест проверяет, открывается ли дверь. Синтетическая транзакция проверяет, можете ли вы войти, сесть, заказать еду, заплатить и уйти с чеком.

Во-вторых, синтетические транзакции проверяют корректность данных, а не только доступность страницы. Smoke-тест подтверждает, что страница логина загружается. Синтетическая транзакция подтверждает, что после входа пользователь видит свою панель с правильными данными. Это гораздо более сильный сигнал.

Синтетические транзакции должны запускаться сразу после завершения деплоя. Они не предназначены для замены долгосрочного мониторинга. Их цель — дать быстрый ответ: «Достаточно ли эта версия стабильна, чтобы продолжать обслуживать пользователей, или нужно откатываться?»

Запускайте оба этапа сразу после деплоя

Smoke-тесты и синтетические транзакции лучше всего работают как двухэтапный пайплайн верификации.

Шаг первый: запустить smoke-тесты. Если они не пройдены — остановитесь. Что-то фундаментально сломано. Откатывайте или исправляйте немедленно. Не переходите к более глубоким проверкам, пока база не работает.

Диаграмма ниже показывает автоматизированный процесс принятия решений:

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

Обе проверки должны завершиться в течение нескольких минут после деплоя. Цель — узнать, безопасна ли новая версия, до того как с ней столкнётся большинство пользователей.

Практический чеклист верификации

Вот простой чеклист, который можно адаптировать под свои деплои:

• Smoke-тест: главная страница возвращает 200
• Smoke-тест: страница логина рендерится без ошибок
• Smoke-тест: критический эндпоинт API отвечает менее чем за 2 секунды
• Smoke-тест: статические ресурсы загружаются корректно
• Синтетическая транзакция: пользователь может войти с тестовыми учётными данными
• Синтетическая транзакция: пользователь может выполнить основной сценарий (например, создать заказ, отправить форму, просмотреть отчёт)
• Синтетическая транзакция: данные, созданные во время теста, видны в ожидаемом месте

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

Как это выглядит на практике

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

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

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

Вот в чём разница между структурированной верификацией и надеждой на лучшее.

Не всё можно проверить одинаково

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

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

Конкретный вывод

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

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