3.2.1 · блок 3
Философия CI/CD: непрерывная интеграция и поставка
Философия CI/CD: непрерывная интеграция и поставка
Зачем это нужно
Вы закоммитили модель и API в Git. Как убедиться, что код собирается, тесты проходят, образ валидный, а в прод не уедет сломанная версия? Ручная проверка «нажми F5 у коллеги DevOps» не масштабируется. CI/CD — автоматизация пути от коммита до работающего сервиса.
Для ML это особенно важно: меняется и код, и данные, и веса модели. Без автоматических проверок легко выкатить inference с несовместимой версией scikit-learn или забыть прогнать smoke-тест predict.
Основные идеи
Continuous Integration (CI). Каждый merge в основную ветку (или каждый PR) запускает пайплайн: lint → unit-тесты → сборка артефакта (Docker-образ, wheel). Цель — раннее обнаружение поломок и единый стандарт качества для всей команды.
Continuous Delivery / Deployment (CD). Delivery — артефакт *готов* к выкладке (образ в registry, manifest обновлён). Deployment — выкладка в prod автоматическая (часто через GitOps и Kubernetes). В корпоративном контуре курса: Jenkins делает CI + push образа; Argo CD (позже) синхронизирует Helm-релиз в кластер.
Pipeline as Code. Пайплайн описывается в репозитории (Jenkinsfile), а не кликами в UI. Версионируется, ревьюится, воспроизводится на другом Jenkins.
Стадии и quality gates. Типичная цепочка для ML-сервиса:
1. Lint — стиль кода, статический анализ.
2. Test — pytest, проверка формата входа/выхода модели.
3. Build — docker build, тег с номером сборки.
4. Push — образ в registry.
5. *(опционально)* Deploy to staging — Helm upgrade в тестовый namespace.
Если стадия красная — дальше не идём. Это quality gate.
CI vs локальная разработка. CI воспроизводит «чистую» среду: нет ваших .venv и забытых env-переменных. Поэтому «локально работает» должно означать «проходит в Jenkins».
Feedback loop. Короткий пайплайн (5–15 минут) мотивирует коммитить чаще. Длинный (час+) — люди копят изменения и сложнее искать причину падения.
Как это выглядит на практике
Story в Jira: «Добавить эндпоинт batch-predict». Разработчик открывает PR. Jenkins Multibranch Pipeline:
1. Checkout кода из PR.
2. pip install -r requirements-dev.txt && ruff check .
3. pytest tests/
4. docker build -t registry/ml/scorer:PR-42 .
5. При merge в main — push тега 1.4.0-${BUILD_NUMBER}.
MLE видит зелёную галочку в PR — можно мержить. SRE знает: образ с таким тегом прошёл тесты. Откат — деплой предыдущего тега, не «откатить git и молиться».
Различие CI и CD на примере: CI ответил «образ scorer:128 собран и протестирован». CD (через Helm + GitOps) ответил «в namespace prod крутится scorer:128».
Что сделать после занятия
- [ ] Нарисуйте схему «коммит → prod» для учебного проекта: какие шаги автоматические, какие ручные.
- [ ] Сформулируйте три quality gates для ML-сервиса (не только «тесты зелёные»).
- [ ] Прочитайте Jenkins docs про Pipeline и выпишите, чем Declarative Pipeline отличается от freestyle job.