← Back to notes

CI/CD overview: принципы,
pipeline-as-code, метрики DORA

2026-04-26

#gitops#pipeline#dora

Это оглавление и базовые понятия CI/CD. Детальные разборы — по ссылкам внизу.

CI, CD и Continuous Delivery — в чём разница

Три термина часто смешивают. Разберём строго.

Continuous Integration (CI) — практика, при которой каждый разработчик интегрирует изменения в основную ветку минимум раз в день. Каждый push запускает автоматический билд и тесты. Если сборка сломана — вся команда бросает текущее и чинит прямо сейчас. Мартин Фаулер сформулировал это ещё в 2006: CI — это не инструмент, а дисциплина (martinfowler.com/articles/continuousIntegration.html).

Ключевые практики CI по Фаулеру:

  • единый репозиторий — одна ветка как источник истины (или trunk-based development);
  • автоматизированный билд — ни один шаг не делается вручную;
  • self-testing build — тесты часть сборки, не опция;
  • быстрый билд — pipeline дольше 10 минут уже проблема.

Continuous Delivery (CDelivery) — расширение CI: каждый успешный билд является потенциально деплоябельным в production. Деплой происходит по кнопке, но решение нажать — за человеком.

Continuous Deployment (CD) — каждый успешный коммит автоматически уходит в production без ручного шага. Требует зрелого мониторинга, feature flags и немедленного rollback.

Итого: CI ⊂ CDelivery ⊂ CD. Большинство команд живут на уровне CDelivery — и это нормально.

Стадии pipeline

Типичный современный pipeline выглядит так:

[Commit] → [Lint/Static] → [Unit Tests] → [Build & Image] → [Security Scan] → [Push Artifact] → [Deploy Staging] → [E2E Tests] → [Promote Prod]

Каждая стадия — gate. Не прошёл gate — pipeline стопится, не идёт дальше.

Артефакты и неизменяемость

Иммутабельность артефакта — основа воспроизводимых деплоев.

registry.io/app:abc1234   ← иммутабельный, по commit SHA  ✓
registry.io/app:latest    ← изменяемый pointer            ✗ в prod
registry.io/app:1.4.2     ← semver тег для релизов        ✓

Почему latest запрещён в prod: два деплоя с тегом latest могут тянуть разные образы, если между ними кто-то пушнул новую сборку. Воспроизводимость теряется, откат становится угадыванием.

Image promotion — CI не собирает новый образ для каждого окружения. Собранный образ по SHA переезжает из staging в prod через обновление значения тега в GitOps-репозитории. Один образ — одна сборка.

Pipeline-as-code

Pipeline описывается в файле в репозитории, а не через UI. Это даёт версионирование, code review и аудит-трейл для самого CI.

GitHub Actions (пример):

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Build and push
      uses: docker/build-push-action@v5
      with:
        tags: registry.io/app:${{ github.sha }}
    - name: Trivy scan
      uses: aquasecurity/trivy-action@0.28.0  # pin version, не @master
      with:
        image-ref: registry.io/app:${{ github.sha }}
        severity: CRITICAL,HIGH
        exit-code: 1

GitLab CI (пример):

stages: [build, test, scan, push, deploy]

build:
  stage: build
  script:
  - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .

trivy:
  stage: scan
  script:
  - trivy image --exit-code 1 --severity CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Два правила, которые нарушают чаще всего:

  1. Пинить версии actions — @master или @latest в экшнах это supply chain attack surface. Пиши SHA или точную версию.
  2. Caching — actions/cache для node_modules, .m2, pip, go mod; --cache-from в Docker. Без кэша pipeline 5 минут превращается в 15.

Secrets management

Хранить секреты в Git нельзя ни в каком виде — ни plaintext, ни base64. Три подхода для GitOps:

ESO (external-secrets.io) — наиболее зрелый вариант для серьёзного масштаба: централизованное управление, rotation без деплоя, полный audit log.

В самом CI (GitHub Actions / GitLab) — секреты через encrypted variables платформы, никогда не в коде и не в логах.

Метрики DORA

DORA (DevOps Research and Assessment) — четыре метрики, которые статистически коррелируют с бизнес-результатами. Данные из ежегодных отчётов Google DORA (dora.dev/research/).

Первые два — метрики скорости (throughput). Последние два — метрики стабильности (stability). Elite performers улучшают обе оси одновременно — это опровергает старый миф «быстро или надёжно».

Как применять: не как KPI для давления, а как диагностику. Если Lead Time 2 недели — ищи где pipeline тормозит или где approval-loops. Если Change Failure Rate 20% — смотри на coverage, staging-окружение, процедуры review.

Trunk-based vs Feature-branch

Trunk-based — предпосылка для настоящего CI. Если ветка живёт 2 недели, это не непрерывная интеграция, это периодическая интеграция.

Связанные детальные заметки

  • Deployment Strategies — Recreate, Rolling Update, Blue-Green, Canary, Shadow. Когда что выбирать, примеры с Kubernetes, Istio и Argo Rollouts.
  • Argo CD GitOps delivery — Sync policy, drift detection, guardrails, rollback через git revert, ApplicationSet, multi-cluster.

Ссылки

CI/CD overview: принципы, pipeline-as-code, метрики DORA | Aleksandr Suprun