ci-cd-pipeline.js·3 scenarios
CI/CD pipeline: GitHub, Build/Test runners, Docker, Artifact Registry, Staging, Production, Monitoring
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: 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.
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-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.