Непрерывное развертывание

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: если p95>порог, error rate↑, бизнес-метрика↓ — авто-стоп/откат.
Release Dashboards: виджеты: версия→метрики→флаги→канареечные доли трафика.
Алерты: уровни шумоподавления, ротации 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/финтех)

Трассируемость: требование→тикет→PR→билд→артефакт→среда→лог в аудите.
Geo-release: по странам/юрисдикциям, с локальной конфигурацией платежей/KYC.
Антифрод/риск-движки: канареечные трафик-пулы, мониторинг 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, фича-флаги, наблюдаемость и воспроизводимость каждого шага.