Staging-пайплайны и релизы

1) Зачем нужен staging-пайплайн

• воспроизводимость сборки и релиза;
• быстрый и предсказуемый фидбек;
• минимизация риска (прогрессивные раскатки, фичефлаги, откаты);
• соответствие комплаенсу и контроль изменений.

2) Эталонный поток поставки (high-level)

1. PR → автоматические проверки (lint, unit, SAST, лицензии).
2. Build → детерминированный образ/пакет, подпись и SBOM.
3. Test on Ephemeral → превью-окружение per-PR.

• деплой образа;
• контракт-, интеграционные, e2e-тесты;
• DAST/IAST, регрессы, нагрузочный smoke;
• ручные UAT/QA при необходимости.
• 5. Release Candidate (RC) → freeze window → Prod (canary/blue-green).
• 6. Post-deploy проверки и автооткат по SLO/error budget.
• 7. Runbook/Changelog → закрытие релиза и ретроспектива.

3) Стандартизованный YAML-шаблон пайплайна (выдержка)

yaml
.ci/release.pipeline.yml stages: [verify, build, test, stage, approve, release, post]

verify:
- run: make lint test:unit sbom sast sca build:
- run:
docker build -t registry/app:$GIT_SHA.
cosign sign registry/app:$GIT_SHA oras push registry/sbom:$GIT_SHA sbom.json test:
- run: make test:contract test:integration
- run: make deploy:preview && make test:e2e stage:
- run: make deploy:staging IMAGE=registry/app:$GIT_SHA
- run: make test:e2e:staging && make dast approve:
manual gate: CAB/QA lead
- type: manual required_roles: [release_manager, qa_lead]
release:
- run: make release:canary TRAFFIC=5%
- run: make release:progressive STEPS="5,25,50,100"
post:
- run: make verify:slo && make notify && make create:changelog

4) Gates и критерии готовности (Quality Gates)

Код и безопасность: линты, покрытие, SAST/SCA, политика зависимостей, отсутствие «critical/high».
Контракты: совместимость схем (API/события), Pact/Buf проверки.
Тесты: unit/integration/e2e p-порог прохождения, стабильность (flake-rate).
Нагрузочные smoke: p95/p99 в рамках бюджета, нет деградаций.
DAST/IAST: нет критичных findings, пен-тест сценарии для чувствительных путей.
Observability: дашборды/алерты «as code» обновлены, runbooks приложены.
CAB/UAT: подтверждение в окнах релиза (если требуется регуляторикой/бизнесом).

5) Релизные стратегии

Canary — постепенное увеличение доли трафика (5% → 25% → 50% → 100%), автоматический roll-forward/rollback по SLO и аномалиям.
Blue-Green — параллельные среды; мгновенный переключатель, простой откат.
Feature Flags — логическое включение фич без redeploy; возможность «dark launch» и A/B.
Shadow/Traffic Mirroring — пассивный прогон трафика на новую версию без влияния на пользователей.
Ring Deployments — волны по регионам/тенантам.

6) Откаты и политика безопасности релизов

Автооткат по триггерам: рост error-rate, p95/TTFB выше порога, рост 5xx/timeout, всплеск DLQ.
Ручной откат: команда `/rollback <service> <sha>` в чат-боте, одна кнопка в релиз-консоли.
Freeze windows: запрещен релиз в критические события (турниры/пиковые матчи).
Changelog & Release Notes: генерация из PR, теги SemVer, компоненты, миграции.

7) Миграции БД и совместимость

1. добавить совместимые поля/индексы;

2. деплой приложения (читает/пишет в обе схемы);

3. миграция данных фоновыми джобами;

4. удалить старое.

Схемы версионируются, миграции idempotent, dry-run в staging.

Protect destructive SQL: require flag/approval, автоматические бэкапы и plan-check.

8) Фичефлаги и прогрессивная активация

Разделяйте ops-флаги (для безопасной эксплуатации) и product-флаги.
Включение по аудитории: процент, гео, тенант, роль.
Метрики флагов: влияние на конверсию, latency, ошибки.
При проблемах — свертка флага быстрее отката.

9) Observability как часть релиза

Трейсы: сквозной `trace_id` от gateway до БД/очередей; сравнение старой/новой версий.
Метрики: p50/p95/p99, error-rate, RPS, saturation, DLQ, ретраи, Time-to-Wallet/Business KPI.
Логи: структурированные, маскирование PII, корреляция `request_id`.
Алерты: SLO-бюджет, срочные страницы on-call, авто-свертка релиза.

10) Безопасность цепочки поставки (supply chain)

SBOM на каждый билд, хранение и привязка к тегу релиза.
Подписи образов (cosign), проверка на кластере (policy admission).
SLSA-аттестации: доказуемое происхождение артефакта.
Policy-as-Code (OPA/Conftest): deny-by-default для инфраструктурных PR.
Секреты: только из KMS, короткоживущие токены, ротации в пайплайнах.

11) Контроль изменений и процессы

RFC → CRQ → CAB: документируемую смену поведений/контрактов согласовываем заранее.
Release Calendar: видимые окна по продуктам/регионам/командам.
Runbooks: для каждого компонента — процедуры включения/отката/диагностики.
Postmortem/Retro: после значимых релизов — анализ и действия.

12) Профили тестов на staging

Контрактные (API/Events): блокируют несовместимые изменения.
Интеграционные/e2e: сквозные сценарии «депозит», «KYC», «вывод».
Нагрузочные smoke: репрезентативные пики; следим за ресурсными лимитами.
Хаос-сценарии: отключение провайдера, рост латентности, сетевые флаппинги.
Синтетический мониторинг: «пробные» транзакции по расписанию.

13) Пример Makefile целей релиза (фрагмент)

makefile release: verify build test stage approve prod post verify:
@make lint test:unit sbom sast sca build:
docker build -t $(IMG).
cosign sign $(IMG)
test:
@make test:contract test:integration deploy:preview test:e2e stage:
kubectl apply -k deploy/staging approve:
@echo "Waiting for QA/CAB approval..."
prod:
make release:canary TRAFFIC="5 25 50 100"
post:
@make verify:slo notify changelog

14) Роли и ответственности

Dev/Team: качество кода, тесты, миграции, runbooks.
QA: сценарии UAT/regression, контроль качества на gates.
SRE/Платформа: надежность пайплайнов, наблюдаемость, политики.
Release Manager: календарь, окна, CAB, финальное решение.
Security: SAST/DAST/SCA, supply-chain, политика секретов.

15) Модель зрелости релизов

1. Базовая — ручные проверки, редкие релизы, откаты трудны.
2. Продвинутая — стандартизованный CI/CD, staging-контур, canary/blue-green, частые релизы.
3. Экспертная — прогрессивная доставка по тенантам/регионам, feature flags-first, policy-as-code, автооткат по SLO, полная трассируемость и SLSA.

16) Дорожная карта внедрения

M0–M1 (MVP): шаблон пайплайна, build+sign+SBOM, staging-деплой, базовые тесты и gates.
M2–M3: canary/blue-green, превью per-PR, контракт-тесты, DAST, synthetic checks.
M4–M6: feature flags платформа, shadow traffic, policy-as-code, автооткат, release calendar + CAB-воркфлоу.
M6+: ring-deployments по регионам, SLSA-аттестации и строгий admission, полная автоматизация runbooks.

17) Чек-лист перед прод-релизом

• Образ подписан, SBOM загружен и привязан к релизу.
• Контракты совместимы, тесты зеленые, e2e прошли на staging.
• Миграции проверены (dry-run), бэкап готов, план отката описан.
• Дашборды/алерты обновлены, SLO-гейты активны.
• Runbook и Changelog опубликованы, окна релиза согласованы.
• Feature flags настроены на прогрессивную активацию.
• Freeze-ограничения соблюдены, on-call готов.

Краткий вывод

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