Безперервне розгортання

1) Що таке CD і чим воно відрізняється від CI/CD

Безперервне розгортання (Continuous Deployment, CD) - це практика автоматичного викату кожного минулого перевірки зміни в прод, без ручних «релізних поїздів». Від CI (автоматичні збірки і тести при комітах) CD відрізняється тим, що завершує ланцюжок: код → артефакт → перевірка → продакшен. У регульованих галузях CD часто комбінують з progressive delivery (поетапний випуск з обмеженням аудиторії).

• Скоротити Time-to-Market і вартість змін.
• Зменшити ризик великих релізів: маленькі партії → простіше знайти причину і відкотити.
• Навести дисципліну якості: «кожен коміт - потенційно продовий».

2) Базові принципи

Малі інкременти. Короткі фіче-гілки, швидкі рев'ю, агресивний мерджинг.
Детермінованість збірки. Повторювані білд-оточення, lock-файли, hermetic builds.
Shift-left-якість. Лінтери, статичний аналіз, юніт/контрактні тести до інтеграції.
Production-like оточення. Ідентичні конфіги, секрети через vault, дані - синтетичні/знеособлені.
Автоматизація всього шляху. Від коміту до маршрутизації трафіку і відкату.
Спостереження за замовчуванням. Метрики, логи, трасування, алерти - як частина Definition of Done.
Безпека-by-design. SAST/DAST, SCA, підписані артефакти, перевірка політик.

3) Еталонна архітектура пайплайна CD

1. Trigger: подія в VCS (push/merge), позначена як «prod-eligible».
2. Build: збірка артефакту (image, пакет), SBOM, підпис (Sigstore/Cosign).
3. Test Fast: лінт/юніт/контрактні; швидкий feedback (<5-10 хв).
4. Test Deep (в паралелі): інтеграційні, E2E, навантажувальні «за профілем», хаос-проби в стейджі.
5. Security Gate: SAST/DAST/SCA, перевірка секретів, перевірка політик (OPA/Conftest/Kyverno).
6. Compliance Gate: SoD/4-очі при необхідності, трассируемость вимог, чек-листи.
7. Promote: просування артефакту як одного і того ж білда через середовища (dev → stage → prod).
8. Deploy Strategy: blue-green / canary / progressive + feature flags.
9. Post-Deploy Verification: auto-health, SLO/SLA, алерти, авто-ролбек при деградації.
10. Audit & Evidence: артефакти, логи, протоколи перевірок - у незмінному сховищі.

4) Стратегії релізів

Blue-Green: два прод-стенди (Blue = поточний, Green = новий), атомарне перемикання маршрутизації. Плюс - миттєвий відкат. Мінус - подвійна інфраструктура.
Canary: порційний пуск трафіку (1% → 5% → 25% → 100%) з автоматичними SLO-гейтами.
Progressive Delivery: цільові когорти (регіон, провайдер, VIP-сегмент), ліміт радіусу ураження.
Feature Flags: поставка коду «вимкненим», включення за користувачами/коhortам. Обов'язково: політика «flag lifecycle».

5) Тестування та якість

Контрактні тести і consumer-driven contracts для незалежних релізів мікросервісів.
Навантажувальні профілі по реальних патернах (RPS, p95/p99, відкриті/закриті моделі).
Тести міграцій БД: прямі/оборотні, сумісність двох версій (expand → contract).
Chaos/Resilience-проби: відключення залежностей, мережеві затримки, ліміти ресурсів.
Пострелізна перевірка (smoke + synthetic) з точок, близьких до користувача.

6) Безпека і комплаєнс в CD

Підпис артефактів, provenance, SBOM. Відстежуємо походження, виключаємо «supply chain» ризики.
Policy-as-Code: допускаємо до прод тільки образи з довіреного реєстру, зі скан-проходженням.
Секрети: short-lived токени, ротовані ключі, KMS; заборона секретів в гіті.
Розподіл обов'язків (SoD): розробка ≠ прод-доступ; всі операції - через пайплайн.
Аудит-слід: незмінювані логи релізів, хто/що/коли; зберігання N років з регуляторики.

7) Управління змінами та ризик-контроль

Change Types: стандартні (повністю автоматичні), нормальні (авто + схвалення), екстрені (прискорене вікно + post-mortem).
CAB-мінімалізм: CAB для змінених ризиків і інфраструктурних «ламаючих» апдейтів, інше - через автоматичні гейти якості.
Risk Matrix: вплив × ймовірність → вибір стратегії (canary глибше, прапори, додатковий моніторинг).
Runbooks & Playbooks: чіткі інструкції на кожен тип випуску і відкату.

8) Спостережуваність, SLO і авто-ролбек

Золоті сигнали: латентність, помилки, насичення, трафік; бізнес-метрики (конверсія, депозит, успіх платежів).
Guardrails: якщо р95> поріг, error rate↑, бізнес- metrika↓ - авто-стоп/відкат.
Release Dashboards: віджети: versiya→metriki→flagi→kanareyechnyye частки трафіку.
Алерти: рівні шумозаглушення, ротації on-call, зв'язок з інцидент-менеджментом.

9) Метрики CD

DORA-метрики: частота деплоїв, lead time for changes, MTTR, частка невдалих релізів.
Change-failure-rate на когортах (по провайдеру, регіону, пристрою).
Час проходження гейтів: де «вузькі місця» (security scan, інтеграційні тести).
Cost-to-Release: вартість хвилини вікна, інфраструктурна націнка стратегій (blue-green vs canary).

10) Патерни відкатів і сумісність

Авто-ролбек: на рівні маршрутизації (traffic switch) та/або версіонування (K8s rollout undo).
БД-міграції: стратегія expand-migrate-contract, фіча-прапори приховують недоступні поля.
Idempotency & Exactly-once-like: для черг/платежів - ключі ідемпотентності, дедуплікація.
Back-pressure и graceful degradation: при деградації - відключати нефункціональні фічі.

11) Практична модель оточень

GitOps-підхід: цільовий стан зберігається в гіті, контролер застосовує маніфести.
Environments: 'dev'( швидко і брудно),'stage'( прод-like, хаос-проби),'prod-A/B'( blue-green) або'prod'з canary-пулами.
Ізоляція даних: конфіги як дані, секрети поза образом, окремі обліки/ліміти.

12) Процеси і ролі

RACI: Архітектор (політики), Платформна команда (пайплайн, кластера), Команди продукту (тести/прапори), Безпека (політики/скани), SRE (SLO/надійність).
ChatOps: релізи з PR-ботів, видимість статусів, «/promote », «/rollback».
SOP: чек-листи релізу, post-release review, контроль «aging» прапорів.

13) Особливості для високорегульованих доменів (наприклад, iGaming/фінтех)

Трасування: trebovaniye→tiket→PR→bild→artefakt→sreda→log в аудиті.
Geo-release: по країнах/юрисдикціях, з локальною конфігурацією платежів/КУС.
Антифрод/ризик-движки: канарні трафік-пули, моніторинг false-positive/negative.
KYC/AML/відповідальна гра: фічі випускати через прапори з обов'язковим моніторингом призначеного для користувача впливу.

14) Часті анти-патерни

Ручні кроки між стадіями («принесли артефакт руками»).
«Сірі прапори» без власника і терміну життя.
Один загальний «товстий» інтеграційний тест замість контрактів.
Відсутність оборотних міграцій БД.
Скан безпеки після деплою, а не до.

15) Міні-чек-лист готовності до CD

• Білд детермінований; артефакт підписаний; є SBOM.
• Контрактні тести і фікстури для E2E.
• Security/Compliance-гейти як код; секрети - через vault.
• Спостережуваність: логи/метрики/трейси, релізні дашборди, SLO-гейти.
• Стратегія випуску: canary/blue-green + авто-ролбек.

Процедури міграцій БД (expand/contract).

• Feature flags з політикою «створив → використовував → видалив».
• RACI/Runbooks/ChatOps інтеграції.

16) Приклад потоку (сценарій)

1. Merge в'main'тригерит пайплайн.
2. Збірка контейнера, підпис, SBOM.
3. Лінт/юніт/контракти → пройдено.
4. SAST/SCA/секрет-скан → «зелений».
5. Автопромо в stage: E2E + хаос + навантаження за профілем.
6. Canary 1% в прод, контроль помилок/латентності/бізнес-метрик.
7. Ескалація до 25 %/50 %/100% при зелених гейтах.
8. Автозакриття прапора «rollout-guard», запис артефактів аудиту.
9. Post-release review, видалення тимчасових прапорів.

17) Підсумок

CD - це не «кнопка деплою», а культура маленьких, безпечних і спостережуваних змін. З правильними політиками і автоматизацією CD зменшує ризики, прискорює поставку цінності і робить релізи рутиною, а не подією. Для високонавантажених і регульованих систем ключ до успіху - строгі гейти якості, поетапний rollout, фіча-прапори, спостережуваність і відтворюваність кожного кроку.