ci cd

CI/CD (Continuous Integration / Continuous Delivery или Deployment) — это набор практик и инструментов DevOps, автоматизирующих сборку, тестирование и доставку программного обеспечения. CI/CD превращает процесс выпуска новых версий из редкого болезненного события в рутинную автоматическую процедуру, позволяя командам выпускать изменения безопасно и часто — вплоть до нескольких раз в день.

Continuous Integration (CI)

Continuous Integration — практика, при которой разработчики регулярно (в идеале — после каждого коммита) интегрируют свой код в общую ветку, а автоматизированная система немедленно запускает сборку и набор тестов. Цель — обнаружить конфликты интеграции и регрессии как можно раньше, пока их исправление стоит минимум усилий.

Типичный CI pipeline включает:

1. Checkout кода из репозитория
2. Установка зависимостей
3. Статический анализ и линтинг
4. Компиляция / сборка артефактов
5. Unit и интеграционные тесты
6. Сканирование безопасности (SAST, dependency audit)
7. Сборка Docker-образа и его публикация в registry

Continuous Delivery vs Continuous Deployment

Между этими двумя понятиями есть важное различие:

Continuous Delivery означает, что каждое изменение, прошедшее CI, готово к развёртыванию в production, но фактический деплой запускается вручную. Команда сохраняет контроль над тем, когда именно изменения попадают к пользователям.

Continuous Deployment идёт дальше: каждое изменение, прошедшее все проверки, автоматически деплоится в production без ручного вмешательства. Это требует высокого уровня зрелости тестирования и мониторинга.

Популярные инструменты CI/CD

• GitHub Actions — встроенная CI/CD-система GitHub, YAML-конфигурация прямо в репозитории
• GitLab CI/CD — мощная система с встроенным container registry и environments
• Jenkins — классическое self-hosted решение с огромной экосистемой плагинов
• CircleCI, Travis CI — облачные CI-платформы
• ArgoCD, Flux — GitOps-инструменты для CD в Kubernetes
• Woodpecker CI — лёгкий open-source форк Drone

Ключевые концепции пайплайна

Pipeline as Code: конфигурация пайплайна хранится в репозитории рядом с кодом (Jenkinsfile, .gitlab-ci.yml, .github/workflows/*.yml). Это даёт версионирование, code review для изменений пайплайна и воспроизводимость.

Stages и Jobs: пайплайн делится на стадии (build, test, deploy), внутри которых выполняются задания (jobs). Задания могут работать параллельно для ускорения.

Artifacts: результаты сборки (JAR, Docker image, compiled binary) сохраняются и передаются между стадиями или хранятся для последующего использования.

Environments: типичный флоу — development → staging → production. Каждый environment может требовать ручного подтверждения перед деплоем.

Feature Flags и Canary Deployment

Зрелые CD-системы используют продвинутые техники снижения риска. Feature flags позволяют деплоить код, но включать функциональность только для части пользователей. Canary deployment постепенно направляет трафик на новую версию: сначала 1%, затем 10%, 50% и, если метрики в норме, 100%.

Blue-green deployment поддерживает две идентичные production-среды и переключает трафик мгновенно, что позволяет быстро откатиться при проблемах.

Метрики зрелости CI/CD

DORA-метрики (DevOps Research and Assessment) — стандарт оценки эффективности delivery:

• Deployment frequency — как часто деплоятся изменения
• Lead time for changes — время от коммита до production
• Change failure rate — процент деплоев, вызвавших инциденты
• Mean time to recovery — время восстановления после инцидента

Elite performers деплоят несколько раз в день при change failure rate менее 5%.

Security в CI/CD пайплайне

Безопасность должна встраиваться в CI/CD, а не добавляться после. Практика «shift left security» означает проверку безопасности на ранних этапах: SAST (статический анализ: Semgrep, CodeQL) запускается при каждом PR, dependency scanning (Dependabot, Snyk) отслеживает уязвимые зависимости автоматически, secret scanning предотвращает попадание API-ключей и паролей в репозиторий. Container scanning (Trivy, Grype) проверяет Docker-образы на известные CVE. DAST и penetration testing проводятся на staging-окружении. Подписание артефактов через Sigstore/Cosign обеспечивает supply chain integrity — гарантию того, что образ в registry идентичен собранному в CI.