CI/CD Pipeline

Зачем нужно знать

CI/CD pipeline — это production-система для доставки изменений. Она не просто запускает тесты после push. Хороший pipeline уменьшает размер batch, быстро находит дефекты, делает artifact воспроизводимым, отделяет deploy от release, добавляет контрольные gates и связывает релиз с observability. Без него команда либо боится выкатывать, либо выкатывает вслепую.

Continuous Integration отвечает за постоянное слияние изменений в main: build, lint, type-check, unit tests, integration tests, static analysis, security scan, branch protection. Continuous Delivery доводит каждый green commit до состояния “можно выкатить в production”, но может оставить manual approval. Continuous Deployment идет дальше и выкатывает автоматически, если все gates пройдены. В обоих случаях главный принцип один: маленькие изменения, один immutable artifact, автоматическая проверка, быстрый feedback.

Для архитектора pipeline важен не меньше, чем runtime-схема приложения. Если deploy занимает часы, rollback ручной, migration ломает backward compatibility, а monitoring смотрят после жалоб пользователей, то даже хорошая архитектура будет менятьcя медленно и опасно. CI/CD — это механизм снижения delivery risk.

Mental model

Mental model: commit проходит через конвейер доверия. Сначала source control фиксирует изменение. CI доказывает, что код собирается и проходит тесты. Docker build превращает исходники в immutable artifact с digest. Registry хранит именно этот artifact. Staging проверяет artifact в production-like среде. Approval gate фиксирует человеческое решение там, где оно нужно. Production deploy берет тот же digest, а monitoring подтверждает, что система здорова после изменения.

Ключевая мысль: build once, deploy many. Нельзя собирать заново для staging и потом заново для production, потому что это уже разные artifacts. Если staging проверил image sha256:..., production должен получить тот же image. Иначе gate проверял не то, что было выкачено пользователям.

ADR-решение обычно фиксирует: pipeline-as-code в репозитории, immutable artifacts, обязательный green CI до merge, staging smoke tests, production rollout strategy, rollback policy, ownership алертов и правила для database migrations.

Что показывает диаграмма

Диаграмма показывает линейный pipeline: Git Repository и Webhook, CI Server с Build Runner, Test Runner и Docker Build, Artifact Registry, Staging Environment со staging deploy, smoke tests и approval gate, Production Environment с production deploy и health checks, Monitoring с Prometheus/Grafana и Alert Manager.

Связи отражают реальные зависимости. Git push вызывает webhook, webhook триггерит build runner, build output идет в tests, успешные tests разрешают Docker build, image отправляется в artifact store. Staging и production оба берут artifact из registry. Production после deploy отправляет metrics и status в monitoring, а alerting оценивает правила.

Диаграмма намеренно не показывает pipeline как один “CI box”. Она разделяет стадии, потому что у каждой свой failure mode: flaky tests, медленный build, уязвимый image, broken staging env, ручной approval bottleneck, failing readiness probes, плохие alert thresholds.

Сценарии и что они учат

Feature Branch показывает путь от push до artifact. Developer отправляет branch, webhook запускает CI, build runner компилирует, test runner выполняет unit и integration tests, Docker build создает image, registry сохраняет release candidate. Урок: CI должен завершаться конкретным artifact, а не только словами “tests passed”.

Deploy to Staging показывает проверку того же artifact в pre-production. Staging pulls image, smoke tests проверяют API health, DB connectivity и auth flow, результаты идут в approval gate. Урок: staging gate должен проверять критические интеграции, а не повторять только unit tests. Smoke tests короткие, но покрывают user-visible path.

Production Release показывает promotion после approval. Production выполняет rolling update, pulls production tag или digest из registry, readiness/health checks проверяют новые pods, metrics уходят в Prometheus, Alert Manager оценивает error rate и latency. Урок: deploy не закончен, пока post-deploy monitoring не подтвердил здоровье.

Эти сценарии показывают базовую delivery loop. В зрелой системе к ней добавляются canary, blue-green, automated rollback, security attestation, SBOM, migration checks, feature flags и DORA metrics.

Trade-offs

ADR: Continuous Delivery vs Continuous Deployment. Delivery оставляет ручное решение перед production и подходит для regulated доменов, больших customer-facing изменений или команд, где business owner должен выбрать окно релиза. Deployment автоматически катит green changes и снижает lead time, но требует зрелых тестов, fast rollback, feature flags и сильной observability.

ADR: One pipeline per repo vs centralized pipeline. Pipeline-as-code рядом с приложением делает изменения прозрачными для команды и проходит code review. Централизованный pipeline упрощает стандарты security и compliance, но может стать bottleneck и скрыть детали от разработчиков. Практичный компромисс: shared reusable workflows плюс локальная декларация стадий.

ADR: Build once vs rebuild per environment. Rebuild per env кажется удобным для разных конфигов, но ломает воспроизводимость. Build once требует выносить environment config в runtime: env vars, config maps, secrets, feature flags. Это дисциплинирует artifact и делает staging-проверку значимой.

ADR: Fast pipeline vs exhaustive pipeline. Быстрый CI дает feedback за минуты и поддерживает trunk-based development. Полный test suite может идти дольше и ловить больше интеграционных проблем. Обычно делают уровни: mandatory fast checks before merge, heavier nightly или pre-release checks, targeted integration tests по измененным областям.

ADR: Manual approval vs automated gate. Manual approval полезен для production-impacting изменений и compliance, но часто превращается в формальность или очередь. Automated gates по SLO, canary metrics и policy checks быстрее и объективнее. Если manual gate остается, он должен иметь clear owner, SLA и контекст: diff, tests, risk, migration notes.

ADR: Rolling vs blue-green vs canary. Rolling дешевле по capacity и прост в Kubernetes, но rollback может быть постепенным и часть пользователей увидит bad version. Blue-green дает атомарный switch и быстрый rollback, но требует почти двойной capacity. Canary лучше управляет риском через малый процент трафика и метрики, но требует routing, сравнения cohorts и автоматического stop condition.

Реальные системы

GitHub Actions, GitLab CI, CircleCI, Buildkite и Jenkins решают похожую задачу разными операционными моделями. GitHub Actions удобен Git-native workflows. GitLab CI глубоко интегрирован в GitLab. Jenkins живет во многих legacy-организациях и силен plugins, но требует больше ухода. Buildkite часто используют с self-hosted agents. В Kubernetes-native мире встречаются Argo Workflows и Tekton.

Artifact registry может быть Docker Registry, ECR, GCR, GHCR или Artifactory. Важно не название, а свойства: immutable tags или digest-based deploy, retention policy, vulnerability scanning, provenance и access control. Для production нужен audit trail: какой commit, какой image digest, кто approved, когда deployed, какие проверки прошли.

В mature delivery практиках CI/CD связан с DORA metrics: deployment frequency, lead time for changes, change failure rate, time to restore service. Pipeline должен не только доставлять код, но и давать данные о качестве delivery process.

Feature flags часто идут рядом с CI/CD. Pipeline выкатывает код, но release включает поведение отдельно: на 1 процент пользователей, на internal tenants, на один регион. Это снижает риск и помогает rollback без redeploy. Смотри также branch-by-abstraction, где feature flag используется для постепенной замены реализации.

Anti-patterns и типичные ошибки

Первый anti-pattern — собирать artifact заново для каждого окружения. Staging проверяет один бинарь, production получает другой. Это разрушает доверие к pipeline. Второй — использовать mutable tags вроде latest для production deploy. Без digest трудно понять, что реально запущено, и трудно воспроизвести rollback.

Третья ошибка — flaky tests. Если тесты иногда красные без причины, команда перестает уважать CI и начинает rerun-ить до зеленого. Flaky tests должны иметь owner и SLA на исправление или карантин. Четвертая — слишком медленный feedback. Если обязательный CI идет час, разработчики начинают копить большие PR, а это повышает risk.

Пятая ошибка — отсутствие migration strategy. Database changes должны быть backward-compatible: expand/contract, dual-read/dual-write там, где нужно, отдельные migration jobs, idempotency и rollback plan. Нельзя выкатывать app и irreversible schema change без понимания старой версии во время rolling deploy.

Шестая ошибка — manual approval без информации. Approver должен видеть commit range, test status, security findings, migration notes, canary plan и rollback command. Иначе gate не снижает риск, а только добавляет latency.

Седьмая ошибка — считать deploy завершенным после запуска pods. Нужно смотреть readiness, error rate, latency, saturation, logs, business metrics и alerts. Если monitoring не подключен к pipeline, automated rollback невозможен.

Когда НЕ использовать

Не нужно строить тяжелый многоступенчатый enterprise-pipeline для одноразового prototype или локального research script. Там достаточно простого build/test и понятной инструкции запуска.

Continuous Deployment не стоит включать, если нет надежных tests, observability, rollback и feature flags. В такой среде Continuous Delivery с manual production gate безопаснее. Но это не повод оставлять ручные сборки и ручной deploy навсегда: автоматизация до staging и artifact registry все равно дает большую пользу.

Не стоит копировать pipeline больших компаний без учета домена. Финтех, healthcare и инфраструктурные платформы нуждаются в более строгих approvals и audit. Внутренний low-risk сервис может катиться автоматически. Критерий выбора — blast radius, compliance, maturity тестов и стоимость ошибки.

Дальше читать

• containers — почему pipeline часто собирает immutable container image.
• gitops — promotion через декларативное состояние и reconciliation.
• branch-by-abstraction — безопасный refactoring в trunk с feature flags.
• feature-flags — отделение deploy от release.
• blue-green-deployment — атомарное переключение окружений.
• canary-deployment — rollout по проценту трафика и метрикам.
• database-migration — backward-compatible schema changes для rolling deploy.
• observability — post-deploy validation, SLO и automated rollback.
• Jez Humble and David Farley, Continuous Delivery — фундаментальная книга по small batches и deployment pipeline.
• Google DORA metrics — измерение эффективности delivery process.