Базовый pipeline
lint -> test -> build -> deploy staging -> smoke -> deploy prod
Если хотя бы один этап ручной и не описан, это риск инцидента.
Что обязательно
- Preview environments для PR.
- Отдельные секреты staging/prod.
- Автоматический rollback.
- Release notes по каждому деплою.
Post-deploy контроль
Первые 30 минут после релиза:
- 5xx error rate
- latency p95
- критичный conversion step
Чеклист
- PR не деплоится без test/build
- Есть smoke-тест
- Есть rollback-команда
- Есть owner релиза
Environment strategy: минимум для стартапа
Даже маленькой команде нужны хотя бы 3 контура:
- dev/local — быстрые итерации.
- staging — репетиция production с близкими переменными.
- production — только проверенные артефакты.
Ошибка, которую делают часто: staging и prod используют разные внешние сервисы и разные флаги. В итоге "на стейдже работает" не значит ничего.
Что должно быть автоматизировано в первые 30 дней
- Автосборка по каждому PR.
- Автопубликация preview URL.
- Базовый smoke после деплоя.
- One-click rollback на предыдущий image tag.
Если хотя бы rollback не автоматизирован, ваш ночной инцидент будет длиться в 2-3 раза дольше.
Quality gates по уровням зрелости
| Уровень | Что обязательно |
|---|---|
| Start | lint, unit, build |
| Growth | + smoke e2e, dependency audit |
| Scale | + contract tests, load checks, security scans |
Для большинства SaaS-команд на старте достаточно уровня Growth, но к релизу платежей нужен минимум Scale для критичных путей.
Release checklist (операционный)
- Freeze на рискованные миграции БД.
- Назначен release owner.
- Подготовлен rollback plan.
- Дашборды открыты до релиза (errors, latency, conversion).
- Команда знает, кто on-call.
Инцидент после релиза: первые 15 минут
- Подтвердить проблему метриками (не чат-слухами).
- Откатить фичу или релиз.
- Коммуникация в один канал (incident room).
- Фиксировать timeline событий.
Худший сценарий — параллельно «чинить» в 3 местах без координатора.
Частые anti-patterns
- Build зелёный, но миграции не проверяются на staging.
- Секреты хранятся вручную в CI без ротации.
- Нет стратегии фичефлагов и всё релизится "разом".
- Нет пост-релизного контроля продуктовых метрик.
Практическая цель для стартапа
Если вы через 6 недель можете:
- выпускать 3-5 релизов в неделю,
- откатываться за <10 минут,
- не будить команду ночью из-за базовых ошибок pipeline,
значит CI/CD выстроен правильно для вашего этапа.