Спроектируйте автоматические smoke-тесты и health checks сразу после деплоя, которые способны автоматически инициировать откат при обнаружении проблемы

Короткий ответ

Сразу после rollout нужно выполнить короткий набор критичных по бизнес-смыслу проверок (логин, создание заказа, ключевой health-эндпоинт, зависимость от БД) против только что задеплоенной версии, и если хотя бы одна критичная проверка не проходит в течение заданного времени — пайплайн автоматически выполняет откат (`kubectl rollout undo` или возврат трафика на стабильную версию), не дожидаясь, пока проблему заметят пользователи или дежурный инженер.

Как это работает подробнее

смоук-тесты — это маленький, быстрый (обычно до нескольких минут) набор end-to-end проверок, запускаемый как отдельная стадия пайплайна сразу после деплоя, перед тем как считать релиз завершённым. В отличие от readinessProbe (который проверяет готовность одного пода), smoke-тесты проверяют сквозной бизнес-сценарий через реальные API-вызовы.

Пример кода

example.yamlКопировать

smoke_test:
  stage: post-deploy
  script:
    - curl -f https://staging.example.com/healthz
    - npm run test:smoke -- --env=staging
  after_script:
    - |
      if [ "$CI_JOB_STATUS" == "failed" ]; then
        kubectl rollout undo deployment/myapp
      fi

Что использовать на практике

• На практике. важно держать набор именно маленьким и быстрым, покрывающим критичные пути (checkout, авторизация, основной API), а не дублировать весь регрессионный набор — иначе задержка перед подтверждением релиза станет неприемлемой. Автоматический откат по результатам smoke-тестов хорошо сочетается с canary/blue-green: при blue-green можно гонять smoke-тесты на «зелёном» окружении ещё до переключения трафика, вообще не затрагивая пользователей при обнаружении проблемы.
• Пример. Ожидаемое поведение: если `test:smoke` падает (например, сценарий оформления заказа возвращает 500), автоматически выполняется `kubectl rollout undo`, и релиз откатывается без ручного вмешательства, а инцидент фиксируется по логу упавшего smoke-теста.

Подводные камни

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