CI/CD pipeline

Что такое CI/CD pipeline

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

Аналогия прямая: заводской конвейер. Деталь (коммит) движется по станциям, на каждой с ней что-то делают и проверяют. Брак снимают с ленты сразу, а не находят в готовой машине у клиента.

Слово «пайплайн» в разработке используют шире — так называют любую цепочку обработки, где выход одного шага является входом следующего: pipeline данных в ETL, pipeline в инференсе, pipe в Bash (cat log | grep error | wc -l). В контексте CI/CD под пайплайном понимают именно конвейер сборки и доставки.

Из чего состоит

Стадии идут последовательно, задачи внутри одной стадии — параллельно. Провал любой задачи останавливает пайплайн: следующие стадии не запускаются.

Пример пайплайна

.gitlab-ci.yml с параллельными тестами и ручным prod-деплоем:

stages: [build, test, deploy]

variables:
  IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

build:
  stage: build
  image: docker:27
  script:
    - docker build -t $IMAGE .
    - docker push $IMAGE

unit:
  stage: test
  image: $IMAGE
  script: [pytest -q tests/unit]

lint:
  stage: test          # выполняется параллельно с unit
  image: $IMAGE
  script: [ruff check .]

deploy:staging:
  stage: deploy
  script: [kubectl set image deploy/api api=$IMAGE -n staging]
  environment: staging

deploy:prod:
  stage: deploy
  script: [kubectl set image deploy/api api=$IMAGE -n prod]
  environment: production
  when: manual
  only: [main]

Триггеры

• push в ветку — быстрый прогон: линт и unit-тесты;
• merge/pull request — полный прогон, результат блокирует слияние;
• push в main — сборка образа и деплой на staging;
• тег v* — релизный пайплайн в production;
• schedule (cron) — ночные тяжёлые прогоны и бенчмарки.

Что делает пайплайн быстрым

Медленный пайплайн перестают ждать, и он теряет смысл. Практические приёмы:

• Кеш зависимостей между запусками (~/.cache/pip, node_modules) — экономит минуты на каждом прогоне.
• Fail fast: линтеры и быстрые тесты первой стадией, тяжёлые — дальше.
• Параллельность: разбить тесты на несколько задач одной стадии.
• Слои Docker: сначала копировать файл зависимостей, потом код — тогда слой с зависимостями переиспользуется, см. Dockerfile.
• Быстрые runner'ы: сборка упирается в CPU и диск, поэтому runner держат на VPS с NVMe, а не на самой слабой машине.

Пайплайн для ML

У ML-проектов конвейер длиннее: подготовка датасета → обучение или fine-tuning → проверка метрик на валидации → публикация весов в model registry → выкатка сервинга. Стадия обучения требует GPU, поэтому её отправляют на отдельный runner с картой, а лёгкие стадии оставляют на обычных.

Связанные термины

• CI/CD — практика, инструментом которой является пайплайн
• GitLab — .gitlab-ci.yml и runner'ы
• GitHub — GitHub Actions
• Docker Registry — куда пайплайн кладёт образы
• Стратегии деплоя — что происходит на последней стадии
• Тестирование и бенчмарки — содержимое стадии test