CI-CD: принципы, пайплайн, стадии, артефакты
Зачем это на собесе
Базовый вопрос: что такое CI, CD (Delivery и Deployment), из каких стадий состоит пайплайн и что такое артефакт.
Термины
| Термин | Суть |
|---|---|
| CI (Continuous Integration) | частая интеграция изменений в общую ветку с автоматической сборкой и проверками (минимум раз в день на разработчика) |
| Continuous Delivery | каждый успешный коммит готов к выкатке: артефакт собран и протестирован; релиз запускается вручную (кнопка) |
| Continuous Deployment | каждый успешный коммит автоматически попадает в продакшн без ручного шага |
Цель: короткий цикл обратной связи, малые безопасные изменения, воспроизводимые релизы, меньше ручных операций и рисков.
Типовой пайплайн
commit/PR → [build] → [test: unit] → [lint / SAST / SCA] → [package: образ, артефакт]
→ [integration/e2e на review-стенде] → [publish в реестр]
→ deploy dev → deploy staging (smoke/e2e) → [ручное подтверждение] → deploy prod → [post-deploy проверки, мониторинг, откат]Стадии (stages) выполняются последовательно, задания (jobs) внутри стадии — параллельно. Принципы:
- fail fast: быстрые дешёвые проверки (линт, unit) первыми;
- параллелизм независимых заданий;
- детерминированность: одинаковый результат при повторе (фиксированные версии инструментов, закреплённые базовые образы);
- pipeline as code: описание пайплайна в репозитории (
.gitlab-ci.yml,.github/workflows/*.yml,Jenkinsfile); - build once, deploy many: артефакт собирается один раз и продвигается по окружениям;
- изоляция: сборка в чистых контейнерах/раннерах (эфемерные агенты);
- обратная связь: статусы в PR, уведомления, отчёты о тестах и покрытии;
- безопасность: секреты в защищённых переменных, минимальные права токенов, запуск на защищённых ветках.
Артефакты
Артефакт — результат этапа сборки, передаваемый дальше: Docker-образ, .dll/пакет NuGet, dist фронтенда, Helm-чарт, отчёты тестов, SBOM.
- между заданиями пайплайна:
artifacts:(GitLab),actions/upload-artifact(GitHub); - долговременное хранение: реестры (Container Registry, Nexus, Artifactory, NuGet/npm-реестры), с версией и метаданными (коммит, время сборки);
- артефакты неизменяемы и версионируются (SemVer + SHA);
- срок хранения (
expire_in) для временных файлов; очистка.
Окружения и среды
| Окружение | Назначение |
|---|---|
| Review / Preview | временное окружение под MR/PR (ревью фичи) |
| Dev | интеграция последнего main |
| Staging / Pre-prod | копия продакшна для приёмки, нагрузки и smoke |
| Production | реальные пользователи |
Конфигурация и секреты отличаются по окружениям; образ — один и тот же. Защищённые окружения: ручное подтверждение, ограниченный круг, окна релизов.
Триггеры
- push в ветку, создание/обновление MR/PR;
- тег (релиз):
v*; - расписание (nightly сборки, сканирование зависимостей);
- ручной запуск (
workflow_dispatch,when: manual) с параметрами; - вебхук/API, событие другого пайплайна (мультипроектные,
needs/trigger).
Разные сценарии: MR-пайплайн (быстрые проверки), main (полная сборка, публикация, деплой в dev), тег (релиз и прод).
Ключевые практики
- Кэширование зависимостей (NuGet, npm, Docker layers): ускорение.
- Тестовая пирамида в пайплайне: много unit, меньше интеграционных, мало e2e; интеграционные на Testcontainers.
- Статический анализ: линтеры, SAST (Semgrep, SonarQube, CodeQL), сканирование зависимостей (SCA: Dependabot, Trivy), секреты (gitleaks), образы (Trivy).
- Quality gates: порог покрытия, отсутствие критичных уязвимостей, успешные тесты: MR нельзя слить при красном пайплайне.
- Версионирование и changelog автоматически.
- Миграции БД — обратно совместимые, отдельный управляемый шаг.
- Стратегии выкладки: rolling, blue-green, canary, feature flags; откат — возврат предыдущего артефакта.
- GitOps: состояние окружений в Git, агент (ArgoCD/Flux) синхронизирует.
- Наблюдаемость деплоя: метки релиза в мониторинге, автоматический откат по метрикам.
- Метрики: DORA (частота деплоев, lead time, change failure rate, MTTR).
Антипаттерны
- долгий пайплайн (30+ минут) — разработчики обходят;
- нестабильные (flaky) тесты — недоверие;
- ручные шаги «только для релиза» в скриптах на чьём-то ноутбуке;
- пересборка артефакта для каждого окружения;
- секреты в репозитории/логах;
- прямые изменения на сервере в обход пайплайна;
- отсутствие отката;
- пайплайн с правами администратора на всё.
Инструменты
GitLab CI, GitHub Actions, Jenkins, TeamCity, Azure DevOps Pipelines, CircleCI, Drone/Woodpecker, Tekton, Argo Workflows, Dagger. Деплой: Helm, Kustomize, ArgoCD/Flux, Ansible, Terraform, Octopus Deploy.
Вопросы с ответами
Чем Continuous Delivery отличается от Continuous Deployment?
В Delivery каждый успешный коммит готов к выкатке, но релиз в прод запускается вручную; в Deployment выкатка в прод происходит автоматически.
Что такое build once, deploy many?
Артефакт собирается один раз и продвигается по окружениям без пересборки, меняется только конфигурация: так в прод попадает то, что тестировали.
Как сократить время пайплайна?
Кэш зависимостей и слоёв Docker, параллельные задания, fail fast, запуск только затронутых частей (monorepo), лёгкие образы раннеров, разделение быстрых и медленных проверок.