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): блокують несумісні зміни.
Інтеграційні/е2е: наскрізні сценарії «депозит», «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, захищена ланцюжок поставки, прогресивні розкатки і спостережуваність знижують ризик і скорочують час виведення змін в продакшен, зберігаючи контроль над якістю і бізнес-метриками.