Архитектура CI/CD pipeline end-to-end

Действуй как Staff Release Engineer. Спроектируй CI/CD pipeline end-to-end для {{stack}} на платформе {{platform}}. Деплой в {{deploy_targets}} через цепочку {{environments}}. Этот промт — orchestrator: каждая из 7 фаз ниже имеет свои критерии, output-формат и anti-patterns. Пройди их по порядку, не пропуская.

Фаза 1. Trigger design

Дизайн триггеров определяет, кто и когда запускает пайплайн — это первая граница безопасности и производительности.

• Pull request (на feature branch). Лёгкий пайплайн: lint + unit + быстрые integration. Цель — обратная связь автору за ≤ 5 минут. Без публикации артефактов и без доступа к prod-секретам.
• Push в main/release branch. Полный пайплайн: всё из PR + heavy integration + e2e + security + perf. Артефакты публикуются. Триггерит auto-deploy в dev.
• Tag (semver). Релизный пайплайн: ребилд из main commit, подписание артефактов, публикация в реестр, создание GitHub Release с changelog, триггер deploy в staging/prod через approval gate.
• Scheduled (cron). Nightly e2e против staging, security scans (SCA/SAST/DAST), dependency updates (renovate/dependabot), cache warm-up. Это не «бэкап», а активный health-check.
• Manual dispatch (workflow_dispatch). Hotfix-деплой, rollback-кнопка, force-rebuild для невоспроизводимого инцидента. Всегда с required input + approval.
• External trigger (webhook). Из чата (ChatOps), из релиз-менеджера (Linear/Jira), из upstream-репо. Audit log обязателен — иначе невозможно расследовать.

Anti-patterns:

• ❌ Один пайплайн на все триггеры с десятками if — нечитаемо, тесты гоняются «на всякий случай».
• ❌ Запуск тяжёлых job-ов на каждый PR-commit без concurrency: cancel-in-progress — кратные затраты CI-минут.
• ❌ pull_request_target без понимания security implications (доступ к секретам из untrusted кода).

Output фазы 1: таблица Trigger | What runs | Secrets access | Duration target | Output artifacts.

Фаза 2. Build matrix

Build matrix — это произведение «версии × платформы × конфигурации». Цель — поймать платформенно-зависимые баги, но не взорвать длительность.

• Определи измерения: OS (linux/macos/windows), runtime версии (node 20/22, python 3.11/3.12), arch (amd64/arm64), feature flags.
• Marked combinations: какие комбинации обязательны для merge (включи в required checks), какие — best-effort (allow-failure).
• Reproducibility: фиксируй версию toolchain через lockfile / .tool-versions / Dockerfile. Pin actions/images по SHA, не по тегу — теги мутабельны.
• Self-hosted vs hosted runners: self-hosted быстрее на heavy stages (кеш, GPU), но добавляют поддержку. Hosted — стандарт для PR. Никогда не запускай untrusted PR-код на self-hosted runner.
• Build caching см. фазу 8 (отдельный промт).

Anti-patterns:

• ❌ Matrix 5×5×5 = 125 джобов без fail-fast: false или без exclude — впустую сжигается бюджет.
• ❌ Сборка под несколько archs последовательно вместо параллельно через QEMU/buildx.
• ❌ Пины через actions/checkout@v4 без SHA — supply-chain риск.

Output фазы 2: matrix-таблица + список required vs informational чеков + cache-стратегия (link на фазу 8).

Фаза 3. Tests (unit / integration / e2e / security / perf)

Тесты — самая дорогая часть. Дизайн = пирамида с осознанными trade-offs.

• Unit (< 30s суммарно). Без сети, без БД. Параллелятся идеально. Цель: ≥ 80% покрытия бизнес-логики. Хранятся рядом с кодом.
• Integration (1-5 минут). С реальной БД (testcontainers / docker-compose), с моками внешних API. Цель — границы модулей. Изолируй state через transactional rollback или эфемерные схемы.
• E2E (5-20 минут). Playwright / Cypress против полностью развёрнутого приложения. Покрывай критические user-flows (happy path + 2-3 ключевых error path), не всё подряд. Flaky-тесты карантинятся, а не игнорируются.
• Security gates. SCA (Snyk/dependabot) на каждый PR. SAST (CodeQL/Semgrep) на push в main. DAST (ZAP/Burp) nightly против staging. Secret scanning (gitleaks/trufflehog) как pre-commit + CI.
• Performance. k6/Locust против staging как часть release pipeline. Бюджет: p95 latency не растёт более чем на 10% relative to baseline. Lighthouse-бюджеты на фронте.
• Параллелизация: разбей тесты на shards (--shard 1/4 в Jest, pytest-xdist) → запускай как matrix.

Anti-patterns:

• ❌ Только e2e «потому что покрытие 100%» — медленно, flaky, нерасследуемо.
• ❌ Тесты, гоняющие реальные сторонние API в CI — flaky, дорого, риск утечки секретов.
• ❌ if: failure() ignore — flaky тесты накапливаются годами, доверие к suite падает до нуля.

Output фазы 3: пирамида с числами + список required gates + flaky-policy (quarantine, 7 дней на фикс или delete).

Фаза 4. Артефакты (контейнеры / binaries) + SBOM

Артефакт = иммутабельная единица деплоя. После build он не меняется — меняется только то, куда его кладут.

• Naming/tagging: registry/app:<git-sha> всегда. Дополнительно: :<semver> для тегов, :latest только для dev-удобства (никогда в prod-манифесте).
• SBOM (CycloneDX / SPDX): генерируй на build (syft), храни рядом с артефактом, аттачь как OCI artifact. Без SBOM невозможно отвечать на CVE-уведомления.
• Signing: cosign keyless с Sigstore. Подпись + аттестация (provenance SLSA level 3+). На deploy проверяй подпись (admission webhook или Kyverno).
• Vulnerability scan post-build: Trivy/Grype на готовом контейнере. Блокирующий fail при CRITICAL без accepted-risk файла.
• Регистр и retention: prod-артефакты — 90+ дней. PR-артефакты — 7 дней с автоудалением. Используй immutable tags (ECR/GHCR feature).
• Размер: distroless / scratch как база где возможно. Multi-stage build обязателен. Целевой размер — ≤ 100 MB для большинства сервисов.

Anti-patterns:

• ❌ :latest в production deployment — невозможно понять что задеплоено.
• ❌ Rebuild артефакта на каждый environment («build for staging», «build for prod») — два разных артефакта, два разных risk profile.
• ❌ Секреты, вшитые в образ (env-переменные на build-time).

Output фазы 4: artifact spec — name pattern, signing, SBOM location, scan policy, retention.

Фаза 5. Deploy strategy (per environment)

Каждое окружение имеет свою стратегию — выбор зависит от риска, statefulness и трафика. См. отдельный промт deployment-strategies-choice для decision tree.

• Dev. Auto-deploy на push в main. Rolling, без approval. Цель — быстрый feedback. Допустим короткий downtime.
• Staging. Auto-deploy после успешных тестов. Идентичен prod по топологии (не «уменьшенная копия»). Здесь — е2е, perf, security DAST.
• Prod. Approval gate (manual или automated через policy). Стратегия по сервису: stateless web → blue-green / canary, БД-миграции → отдельный пайплайн (см. ниже), batch-jobs → rolling.
• DB migrations. Всегда отдельный пайплайн от деплоя кода. Expand-contract паттерн: миграция совместима со старой и новой версией кода. Никогда не комбинируй DDL и code release в один step.
• Multi-region. Деплой регион-за-регионом с health-check паузой. Никогда не выкатывай во все регионы параллельно.
• Feature flags как дополнение к deploy-стратегии — позволяют отделить deploy от release (см. отдельный промт).

Anti-patterns:

• ❌ Один и тот же deploy-step для всех окружений «для консистентности» — prod нуждается в gates, dev — в скорости.
• ❌ Combined deploy: миграция БД + код в одном PR — невозможно откатить.
• ❌ kubectl apply без --prune или без GitOps-инструмента — orphan-ресурсы копятся.

Output фазы 5: таблица Env | Strategy | Approval | Auto-rollback | DB migration handling.

Фаза 6. Verification (smoke / canary / SLO)

Деплой без verification — это надежда, а не инженерия.

• Smoke tests post-deploy. 5-10 health-проверок: /health, /ready, ключевые endpoints, проверка соединений с БД/queue. Длительность — ≤ 60 секунд. Fail → auto-rollback.
• Canary analysis. Если стратегия canary: split traffic 5% → 25% → 50% → 100% с auto-promotion на основе метрик (error rate, latency p95, saturation). Использовать Flagger / Argo Rollouts.
• SLO-based gating. Сравни post-deploy метрики с baseline (последние 24 часа): error rate, p95 latency, throughput. Регрессия >10% относительно baseline → block promotion.
• Synthetic monitoring. Datadog Synthetics / Checkly прогоняет ключевые user flows каждые 5 минут — реагирует быстрее, чем юзер.
• Real-user monitoring (RUM). Web vitals, JS errors. На deploy — отдельный «release» в Sentry/Datadog для атрибуции ошибок к версии.

Anti-patterns:

• ❌ «Smoke = curl /health» и больше ничего — пропускает 90% реальных проблем.
• ❌ Canary без auto-rollback — кому-то «потом расскажут».
• ❌ Verification только на metric'ах backend без user-perceived (RUM/synthetic).

Output фазы 6: verification checklist с пороговыми значениями + escalation policy при fail.

Фаза 7. Rollback automation

Подробно см. отдельный промт rollback-automation. Здесь — минимум:

• Один-кликом / автоматически на основе триггеров (error spike, SLO breach, health fail).
• Артефакт N-1 готов и проверен (за один шаг назад).
• БД-миграции: forward-compatible (expand-contract) → откатывается только код, миграция остаётся.
• Время от детекции до восстановления (MTTR) — целевой < 5 минут.

Anti-patterns:

• ❌ «Rollback = git revert + полный новый деплой» — медленно, риск нового incident'а.
• ❌ Откат кода без понимания, что миграция БД уже изменила схему.

Output фазы 7: rollback runbook (триггер → команда → verification → коммуникация).

Финальный формат вывода

# Pipeline: <name>

## Phase 1 — Triggers
<таблица>

## Phase 2 — Build matrix
<матрица + required checks>

## Phase 3 — Tests
<пирамида + flaky policy>

## Phase 4 — Artifacts
<spec>

## Phase 5 — Deploy strategy per env
<таблица>

## Phase 6 — Verification
<checklist>

## Phase 7 — Rollback
<runbook>

## Diagram
<mermaid flow триггер → ... → prod-verify>

## Bottlenecks & next steps
<top-3 что улучшить в следующем спринте>

Принцип: хороший pipeline — это не «всё работает», а «всё recoverable». Каждая фаза должна иметь явный rollback-путь и явные критерии failure.