Коротко. Проверка доступности в CI/CD — это smoke-тест после деплоя: пайплайн дёргает health-эндпоинт нового релиза, ждёт код 200 и нужный признак в ответе, и только тогда считает деплой успешным. При провале — автоматический rollback. Это ловит «зелёный деплой, мёртвый сайт» до того, как его увидят пользователи. Но CI-проверка одноразовая — после неё за непрерывным аптаймом следит внешний synthetic-мониторинг сайтов.
Зачем проверять доступность в пайплайне
Самый опасный класс инцидентов — когда пайплайн зелёный, артефакт собрался, поды поднялись, но приложение не отвечает: упала миграция, не подхватился секрет, сломался конфиг. Без постдеплойной проверки вы узнаете об этом от пользователей.
- Smoke-тест — минимальная проверка «приложение живо» сразу после релиза;
- Health-gate — деплой считается успешным только при 200 на health;
- Auto-rollback — провал проверки откатывает релиз;
- Постдеплойный мониторинг — внешний чекер следит дальше.
Curl-проверка в GitHub Actions
Базовый шаг smoke-теста с retry: ждём, пока новый релиз прогреется, и проверяем код ответа.
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy
run: ./deploy.sh
- name: Smoke test health endpoint
run: |
set -euo pipefail
URL="https://example.com/healthz"
for i in $(seq 1 10); do
code=$(curl -sS -o /tmp/body.txt -w "%{http_code}" --max-time 5 "$URL" || echo "000")
if [ "$code" = "200" ] && grep -q '"status":"ok"' /tmp/body.txt; then
echo "Health OK on attempt $i"
exit 0
fi
echo "Attempt $i: HTTP $code, retrying in 6s..."
sleep 6
done
echo "Health check failed after 10 attempts"
exit 1
- name: Rollback on failure
if: failure()
run: ./rollback.shЧто проверять в smoke-тесте
| Проверка | Зачем | Сигнал провала |
|---|---|---|
| HTTP 200 на /healthz | Приложение отвечает | 5xx или таймаут |
| Признак в теле ответа | Отвечает именно приложение, а не заглушка | Нет ожидаемой строки |
| Версия в /version | Задеплоен нужный билд | Старый commit hash |
| Готовность зависимостей | БД и кэш доступны | readiness != ready |
Smoke-тест должен быть быстрым и детерминированным. Один-два запроса с retry, а не полный e2e-прогон. Цель — поймать катастрофу за секунды, а не оттестировать весь продукт.
Retry-логика и таймауты
Новый под не отвечает мгновенно: ему нужно прогреться. Поэтому smoke-тест должен делать несколько попыток с паузой и общим дедлайном. Без retry проверка упадёт на первом же запросе к ещё не готовому релизу и устроит ложный rollback.
После пайплайна — внешний мониторинг
CI-проверка одноразовая: она подтверждает деплой, но не следит за сайтом дальше. Сертификат истечёт через месяц, сторонний API документацию ляжет ночью, DNS уедет — пайплайн об этом не узнает.
enterno.io подхватывает эстафету как непрерывный synthetic-мониторинг: HTTP / SSL / Ping / DNS из регионов RU / EU / US, бесплатно 10 мониторов с интервалом 5 минут (платно — 1 минута / 30 секунд). Через REST API v4 можно прямо из пайплайна создать или включить монитор на новый эндпоинт. А MCP-сервер (16 инструментов для Claude, Cursor, Zed) позволяет агенту запускать проверки доступности из IDE.
FAQ
Чем smoke-тест отличается от e2e?
Smoke-тест проверяет, что приложение вообще живо (1–2 запроса). E2E прогоняет пользовательские сценарии целиком. В пайплайне после деплоя нужен быстрый smoke, e2e — отдельной стадией.
Как сделать auto-rollback по health-check?
В GitHub Actions используйте if: failure() на шаге отката. При провале smoke-теста job помечается failed и запускается rollback-скрипт.
Сколько retry делать в smoke-тесте?
Обычно 5–10 попыток с паузой 5–6 секунд и общим дедлайном до минуты — достаточно, чтобы релиз прогрелся, но не затягивает пайплайн.
Можно ли управлять мониторами из пайплайна?
Да, через enterno.io API v4: создать монитор на новый эндпоинт или включить существующий одним POST-запросом из CI.
Свяжите деплой с мониторингом: поднимите монитор на enterno.io/monitors и управляйте им через API из пайплайна. Дальше: health-check эндпоинты, мониторинг как код, лучшие практики алертинга.