Ci/cd: что это такое и как устроено на реальных примерах

CI/CD (cicd, ci cd) - это практика автоматизации сборки, тестирования и доставки изменений от коммита до продакшена через воспроизводимый pipeline. Устроено это как цепочка шагов: триггер из репозитория, сборка артефакта, проверки качества, публикация и безопасный деплой с возможностью отката. Ниже - как выглядит внедрение CI/CD на реальных примерах.

Краткая схема и практические выводы

Минимальный pipeline: commit → build → test → publish → deploy, с неизменяемыми артефактами и логами каждого шага.
Начинайте с одного сервиса/репозитория и одного окружения; расширяйте после стабилизации и появления метрик.
Разделяйте CI (проверки и сборка) и CD (доставка и развёртывание) по доступам и секретам.
Делайте деплой идемпотентным: повторный запуск не должен ломать среду.
Политики безопасности (секреты, подпись, сканирование) проще внедрять "слева" - в CI, а не после инцидента.
Канареечный или blue/green деплой + автоматический rollback снижают риск релиза сильнее, чем "ручная осторожность".

Архитектура CI/CD: роли, артефакты и поток данных

Базовая идея: каждый коммит порождает проверяемый результат (артефакт), который затем продвигается по окружениям с контролем качества и доступов.

Роли и зоны ответственности

Разработчик - пишет код, тесты, поддерживает быстрый feedback (линтеры, unit-тесты).
DevOps/платформенная команда - поддерживает runner'ы/агенты, шаблоны пайплайнов, секреты, политики.
Безопасность/комплаенс - задаёт требования к зависимостям, секретам, правам, аудит-логам.
QA - определяет критерии готовности и наборы тестов на уровнях unit/integration/e2e.

Ключевые артефакты

Исходники в Git (ветки, теги, PR/MR).
Сборочный артефакт: пакет, бинарник, Docker-образ.
Манифесты развёртывания: Helm/Kustomize, Terraform, Ansible, YAML окружений.
Отчёты качества: тест-репорты, coverage, результаты SAST/Dependency scan.
Логи и аудит: кто запустил, что задеплоено, какой commit/образ.

Поток данных (упрощённо)

Git-событие (push/merge/tag) запускает CI.
CI собирает и тестирует, публикует артефакт в registry/repository.
CD берёт тот же артефакт и применяет изменение в среде (staging/prod).
Мониторинг подтверждает здоровье; при деградации срабатывает откат.

Кому подходит и когда лучше не начинать прямо сейчас

Подходит: командам с регулярными релизами, несколькими окружениями, требованиями к воспроизводимости и аудиту; это типичный "ci cd для devops"-контекст.
Не стоит начинать с "полного" CI/CD, если нет базовой дисциплины Git (code review, ветвление) или нет стабильной сборки локально: сначала стабилизируйте build и тесты, иначе pipeline превратится в "красную гирлянду".

Реальные конвейеры: пошаговые примеры для монолита и микросервисов

Что понадобится (доступы и минимальная инфраструктура)

Репозиторий Git + правила PR/MR (обязательные проверки перед merge).
CI runner/agent (SaaS или on-prem) с доступом к зависимостям и кэшам.
Хранилище артефактов: container registry или пакетный репозиторий.
Секреты: токены, ключи, пароли в secret store (а не в переменных репозитория в открытом виде).
Среды: минимум dev/staging и prod; доступы к ним разделены.
Набор тестов: unit обязательно, интеграционные - по критичности.

Пример 1: монолит (on-prem), один репозиторий → один артефакт

Сценарий: приложение собирается в Docker-образ, тесты выполняются в CI, деплой - на VM/кластер on-prem через Ansible или Helm.

# Пример условного .gitlab-ci.yml (идея, не копируйте без адаптации)
stages: [lint, test, build, publish, deploy]

lint:
  stage: lint
  script:
    - ./gradlew checkstyleMain

test:
  stage: test
  script:
    - ./gradlew test

build:
  stage: build
  script:
    - docker build -t registry.local/app:$CI_COMMIT_SHA .
  artifacts:
    expire_in: 1 week
    reports:
      junit: build/test-results/test/*.xml

publish:
  stage: publish
  script:
    - docker push registry.local/app:$CI_COMMIT_SHA
  only:
    - main

deploy_staging:
  stage: deploy
  script:
    - ansible-playbook deploy.yml --extra-vars "image=registry.local/app:$CI_COMMIT_SHA env=staging"
  only:
    - main

Ключевой момент: деплой использует образ по SHA коммита, а не "latest".
Риск: runner с доступом к prod может стать точкой компрометации. Смягчение: отдельные runner'ы/аккаунты для CD, ограничения сетевого доступа, минимальные права.

Пример 2: микросервисы (облако + Kubernetes), несколько репозиториев → GitOps CD

Сценарий: каждый сервис собирает и публикует свой образ, а развёртывание делается через GitOps (например, ArgoCD): изменение версий образов фиксируется в отдельном репозитории манифестов.

# Пример GitHub Actions (упрощённо)
name: ci
on:
  push:
    branches: [ "main" ]

jobs:
  build_test_publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Test
        run: ./mvnw test
      - name: Build image
        run: docker build -t ghcr.io/org/service:${GITHUB_SHA} .
      - name: Push image
        run: docker push ghcr.io/org/service:${GITHUB_SHA}

Ключевой момент: CD не "выполняет kubectl из CI", а применяет изменения из GitOps-репозитория (аудит, история, откаты).
Риск: рассинхрон версий между сервисами. Смягчение: контрактные тесты, совместимые версии API, "release train" для критичных связок.

Инструментарий и интеграции: когда выбирать Jenkins, GitHub Actions, GitLab CI, ArgoCD

Сравнение инструментов (практически)

Инструмент	Где лучше всего подходит	Поддержка и экосистема	Сложность эксплуатации	Модель затрат
Jenkins	On-prem, гибкие legacy-сценарии, нестандартные интеграции	Очень много плагинов, но качество разнородное	Выше: нужно обслуживать контроллер/агенты/плагины	Инфраструктура + время команды (self-hosted)
GitHub Actions	Репозитории в GitHub, быстрый старт, облачные раннеры	Marketplace actions, хорошая интеграция с GitHub	Средняя: управлять проще, но важны права/секреты	SaaS (лимиты/тарифы) + self-hosted runners при необходимости
GitLab CI	Единый контур "код → CI → registry → окружения", удобно для крупных команд	Сильные встроенные возможности, меньше внешних "костылей"	Средняя: особенно хорошо, если GitLab уже основной	SaaS или self-managed (инфра + лицензия)
ArgoCD	CD для Kubernetes по GitOps, контроль дрейфа конфигураций	Cloud-native экосистема, тесно с Kubernetes	Средняя: нужно выстроить GitOps-репозиторий и права	Обычно self-hosted в кластере (инфра + время команды)

Риски и ограничения перед началом настройки

Что такое CI/CD и как оно устроено на реальных примерах - иллюстрация

Секреты в логах/артефактах: токены могут утечь через echo, stack trace, артефактные файлы.
Слишком широкие права runner'ов: один компрометированный job может дать доступ к продакшену.
Неповторяемые сборки: зависимости "плавают", нет lock-файлов, артефакт не привязан к commit.
Отсутствие стратегии отката: деплой автоматизировали, rollback забыли - риск простоя выше.
Слабая изоляция окружений: staging и prod отличаются, pipeline "проходит", а релиз падает.

Пошаговая инструкция: настройка CI/CD pipeline от нуля до безопасного деплоя

Опишите "контракт" пайплайна и границы ответственности

Зафиксируйте, что относится к CI (сборка, тесты, анализ), а что к CD (продвижение артефакта, деплой, откат). Это упрощает внедрение ci cd и разделение доступов.
- Правило: CD работает только с опубликованными артефактами, а не пересобирает их.
- Правило: продакшен-доступы не нужны CI-задачам lint/test.
Выберите точку старта: один проект, один маршрут релиза

Для монолита чаще проще начать с GitLab CI или Jenkins (on-prem), для облачных репозиториев - с GitHub Actions. Не начинайте сразу со всех сервисов: стабилизируйте шаблон и затем размножайте.
Настройте триггеры и правила запуска

Разведите пайплайны по событиям: PR/MR - только проверки, main - публикация, tag/release - продакшен-деплой. Это базовая настройка ci cd pipeline, снижающая риск случайного релиза.
- PR/MR: lint + unit + минимальный security scan.
- Main: добавьте build/publish.
- Tag: включайте CD в prod и выпуск релизных заметок.
Сделайте сборку воспроизводимой и привяжите артефакты к коммиту

Используйте фиксированные версии зависимостей (lock-файлы), неизменяемые теги образов (SHA), и храните артефакты в registry. Это резко снижает "у меня локально работает".
Включите "quality gates" как обязательные проверки

Сделайте так, чтобы merge в main был невозможен без зелёного CI. На этом этапе внедрение ci cd начинает реально сокращать дефекты в релизах.
- Минимум: lint + unit + сборка.
- Дальше: SAST/Dependency scan, интеграционные тесты, проверка лицензий (если актуально).
Организуйте безопасное хранение секретов и выдачу прав

Секреты храните в secret store или в защищённых переменных CI, ограничивайте доступ по окружениям. Никогда не печатайте секреты в логах и не кладите в артефакты.
- Разные секреты для staging и prod.
- Ротация токенов и минимальные scope.
Выберите модель CD: "push" или GitOps "pull"

Для Kubernetes чаще безопаснее GitOps (ArgoCD), где кластер сам подтягивает декларативное состояние. Для VM/on-prem допустим push-деплой, но строго с отдельными правами и журналированием.
Добавьте rollback и пост-деплой проверки здоровья

После деплоя проверьте readiness/health, ключевые метрики и доступность критичных ручек. При деградации включайте автоматический откат на предыдущую версию.

Гарантии качества: тестирование, статический анализ и политики безопасности в конвейере

Unit-тесты запускаются на каждый PR/MR и являются блокирующими.
Интеграционные тесты запускаются хотя бы на main или по расписанию (если тяжёлые).
Линтер/форматтер дают единый стиль и снижают "шум" в код-ревью.
SAST/проверка зависимостей включены и настроены на управляемый порог (исключения оформляются явно).
Секреты не попадают в репозиторий: есть secret scanning и запрет на коммит секретов.
Артефакты подписываются/версионируются, источник сборки трассируется до commit (traceability).
Права job'ов минимальны: CI без доступа к prod, CD - строго по окружениям.
Логи и отчёты пайплайна сохраняются достаточно долго для расследований и аудита.

Стратегии развёртывания: blue/green, canary, rolling и автоматические откаты

Ошибки, из-за которых CI/CD становится опаснее, а не надёжнее

Деплой "поверх" без контроля версий (например, "latest") - невозможно корректно откатиться.
Rolling-деплой без ограничений (maxUnavailable/maxSurge) - можно уронить доступность при всплеске ошибок.
Canary без метрик и алертов - канарейка становится формальностью, деградация не фиксируется.
Blue/green без миграций БД по безопасной схеме - переключение ломает совместимость.
Откат только приложения, но не конфигурации/миграций - состояние остаётся "в будущем".
Секреты/конфиги меняются вручную вне Git - появляется дрейф, инциденты повторяются.
Нет прогрева/кэширования - после релиза растут задержки, а автосистема считает это "падением".
Отсутствует "остановка конвейера" при инциденте (release freeze) - новый релиз ухудшает ситуацию.

Когда какую стратегию выбирать (коротко)

Rolling - базовый вариант для stateless-сервисов, если есть readiness probes и лимиты на обновление.
Blue/green - когда нужно быстрое переключение и предсказуемый откат, особенно при сложной инфраструктуре.
Canary - когда важно проверить релиз на малой доле трафика и есть хорошие метрики качества.
Авто-rollback - обязателен там, где цена простоя высока и есть чёткие сигналы деградации.

Метрики, мониторинг и управление рисками в CI/CD-процессах

Что измерять, чтобы процесс улучшался, а не усложнялся

Длительность пайплайна по стадиям (где узкое место: тесты, сборка, публикация).
Доля "красных" запусков и топ причин падений (флаки-тесты, зависимости, инфраструктура).
Время от merge до деплоя в staging/prod (lead time) как индикатор предсказуемости.
Частота откатов и причины (качество, миграции, конфигурации).

Альтернативы и упрощения, когда полный CI/CD пока неуместен

CI-only + ручной релиз по чек-листу - если prod-доступы строго ограничены или нет зрелого мониторинга; вы всё равно получаете ценность от автоматических проверок.
CD только в staging, prod вручную - уместно при высоких рисках и отсутствии авто-rollback; помогает отладить деплой без давления продакшена.
GitOps только для критичных сервисов - если микросервисов много, начните с "платформенных" и внешних API, где дрейф конфигураций особенно опасен.
Платформенные шаблоны пайплайна - вместо "каждый пишет свой YAML": снижает ошибки и ускоряет масштабирование на команды.

Практические сомнения и готовые ответы

Чем CI отличается от CD в ежедневной работе команды?

CI проверяет и собирает изменения при каждом коммите/PR, а CD доставляет уже собранный артефакт в окружение. Разделение помогает разграничить права и снизить риск утечки прод-секретов.

С чего начать внедрение CI/CD, если проект уже большой и "хрупкий"?

Начните с CI на PR/MR: линтер + unit-тесты + сборка. Затем добавьте публикацию артефакта и деплой в staging; продакшен подключайте после появления стабильного пайплайна и базового rollback.

Как избежать хранения секретов в репозитории и логах?

Храните секреты в secret store/защищённых переменных CI и ограничивайте их по окружениям. Запрещайте вывод секретов в логах и отключайте сохранение файлов, где они могут оказаться.

Нужен ли отдельный инструмент для CD, если уже есть GitLab CI или GitHub Actions?

Не всегда: для простых сценариев достаточно встроенного CD. Для Kubernetes и требований к аудиту/дрейфу чаще удобнее GitOps (например, ArgoCD), где кластер подтягивает желаемое состояние из Git.

Почему пайплайн "зелёный", а в проде всё равно падает?

Обычно staging не совпадает с prod, отсутствуют интеграционные проверки или некорректны миграции БД. Сближайте окружения, добавляйте smoke-тесты после деплоя и делайте миграции совместимыми с откатом.

Как ускорить настройку CI/CD pipeline без потери качества?

Параллелизуйте тесты, включайте кэш зависимостей и выделяйте тяжёлые проверки в nightly/по расписанию. Критичные проверки оставляйте блокирующими на PR/MR.

Что считать "готовым" CI/CD для команды intermediate-уровня?

Есть воспроизводимая сборка, обязательные проверки перед merge, публикация неизменяемых артефактов и предсказуемый деплой хотя бы в staging. Для prod - стратегия развёртывания и понятный откат, закреплённые в процессе.