Pipeline (конвейер) в контексте CI/CD — автоматизированная последовательность шагов, которые код проходит от момента коммита до доставки в рабочую среду. Термин взят из аппаратного обеспечения: конвейерная обработка (pipeline processing) в процессорах означает параллельное выполнение стадий. В DevOps pipeline — организационная единица автоматизации: каждый шаг выполняется, только если предыдущий завершился успешно.
Как работает
Pipeline запускается при событии — коммит в ветку, создание pull request, нажатие кнопки (manual trigger) или по расписанию (cron). Шаги (steps, stages, jobs) выполняются в runner — изолированной среде: Docker-контейнере, виртуальной машине или голом хосте.
Типичная структура CI/CD pipeline:
- Build — компиляция кода, сборка артефакта (Docker-образ, JAR, npm bundle).
- Test — unit-тесты, integration-тесты, e2e-тесты, проверка покрытия.
- Lint / Security scan — статический анализ кода, поиск уязвимостей в зависимостях (SAST, SCA).
- Publish — загрузка образа в Docker registry, публикация пакета в npm/PyPI/Maven.
- Deploy to staging — развёртывание на staging-среду для финального тестирования.
- Deploy to production — доставка в production (автоматически при CD или вручную при Continuous Delivery).
Шаги могут выполняться параллельно. Например, unit-тесты для разных модулей или линтинг и сборка — одновременно. Параллелизм сокращает общее время pipeline.
Pipeline как код (Pipeline as Code) — принцип хранения конфигурации в репозитории вместе с кодом проекта: .github/workflows/ci.yml (GitHub Actions), .gitlab-ci.yml (GitLab CI), Jenkinsfile (Jenkins), .drone.yml (Drone CI). Это обеспечивает версионирование конфигурации.
История
Термин pipeline применительно к разработке ПО появился в 1990-е вместе с практиками Continuous Integration. Кент Бек в 1997 году описал автоматические build-шаги как часть Extreme Programming. Настоящим поворотным моментом стал 2008 год с появлением Jenkins (тогда Hudson): визуальный редактор pipeline сделал практику доступной без глубоких знаний инструментов. В 2016 году Jenkins 2.0 ввёл Jenkinsfile — декларативное описание pipeline в коде. GitLab CI/CD (2012) и GitHub Actions (2019) popularized YAML-based pipeline as code и сделали это стандартом.
Виды pipeline
- CI pipeline — только сборка и тесты, без деплоя. Запускается на каждый коммит в любую ветку.
- CD pipeline — включает деплой. Запускается при слиянии в main/release-ветку.
- Release pipeline — управляет продвижением артефакта через среды: dev → staging → production. Часто с ручными approve.
- Nightly pipeline — по расписанию (ночью), включает длительные тесты, которые не запускаются на каждый коммит.
На что обращать внимание
Медленный pipeline — главный враг продуктивности. Правило: CI pipeline должен завершаться менее чем за 10 минут. Для достижения этого: кэшируйте зависимости (npm install, pip install) между запусками, используйте параллельные jobs, разделяйте быстрые и медленные тесты. Секреты (API-ключи, пароли) передавайте через Secrets механизм CI-системы — никогда не хардкодьте в yaml. Flaky tests (нестабильные тесты) дестабилизируют pipeline: отслеживайте и исправляйте их приоритетно.
Pipeline и хостинг
В контексте хостинга CI/CD pipeline автоматизирует деплой: push в git → сборка Docker-образа → пуш в Docker Registry → деплой на VPS/Kubernetes. Runner — агент, выполняющий шаги pipeline на сервере. Артефакт сборки — результат (Docker-образ, архив) — хранится между шагами. Staging → Production — типичные среды pipeline. Мониторинг pipeline: Grafana + prometheus metrics из Jenkins/GitLab CI показывают время сборки и частоту падений.