CI/CD для науки о данных: автоматизация модели тестирования с Jenkins и Docker
20 июня 2025 г.Введение
CI/CD (непрерывная интеграция/непрерывная доставка) трубопроводы предназначены не только для веб -разработчиков - они имеют решающее значение для науки о данных и машинного обучения. Автоматизация тестирования и развертывания, команды могут гарантировать, что модели являются надежными и воспроизводимыми. В этой статье мы сосредоточены на создании рабочего процесса CI/CD для модели машинного обучения на основе Python, используя Jenkins в качестве оркестратора трубопровода и докера для контейнерирования окружающей среды. Шаг GIT к репозиторию может быть настроен на запуск Jenkins через веб -крючок, автоматически запустив трубопровод.
Трубопровод начинается, когда ученый для данных занимается кодом и моделью репозитория. Дженкинс, интегрированный с системой управления версиями, автоматически обнаруживает изменение и начинает запускать определенный трубопровод. В каждом запуске Дженкинс проверяет код, устанавливает зависимости в контейнер Docker, выполняет тесты, а затем создает изображение Docker, если тесты проходят. Этот процесс гарантирует, что каждое изменение проверяется в чистой, воспроизводимой среде, прежде чем оно продвигается вперед.
Создание воспроизводимой среды на основе Docker
Чтобы поддерживать воспроизводимость, мы упаковываем код ML и его зависимости в изображение Docker. ПростойDockerfileможет выглядеть так:
FROM python:3.8
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# Copy application code and tests
COPY . .
# By default, run tests
CMD ["pytest", "--maxfail=1", "--disable-warnings", "-q"]
Аrequirements.txtможет включать библиотеки с конкретными версиями. Создание этого контейнера в трубопроводе гарантирует, что все прогоны используют одни и те же версии Python и библиотеки. Например, команда оболочки для создания этого изображения будет на локальном уровне:
docker build -t my-ml-model:latest .
Мы указываем Python 3.8 как базовое изображение и копируем в него файлы проекта ML. АCMDв конце запускает тесты по умолчанию, так что запускdocker run my-ml-model:latestвыполнит всеpytestтесты внутри контейнера.
Использование Docker означает, что результаты испытаний не зависят от хост -машины. Члены команды и серверы CI запускают код в одинаковой среде. Это облегчает воспроизводимость: если тест прошел один раз внутри Docker, он будет проходить каждый раз одинаково. В нашем рабочем процессе Дженкинс будет использовать Docker для построения и даже запуска этого контейнера в рамках конвейера. Например, Дженкинс мог построить изображение, а затем запустить контейнер с помощью команды, подобной:
docker build -t my-ml-model:$BUILD_NUMBER . && \
docker run my-ml-model:$BUILD_NUMBER
Здесь$BUILD_NUMBERявляется переменной Jenkins, которая помечает изображение с текущим номером сборки.
Написание тестов для вашей модели ML
В рабочем процессе CI/CD автоматическое тестирование является ключевым. Мы пишем модульные тесты для нашей модели. Например, используя TensorFlow, мы могли бы проверить, что модель создает выходы правильной формы:
# tests/test_model.py
import numpy as np
import tensorflow as tf
from model import get_model
def test_prediction_shape():
model = get_model() # your model-building function
test_input = np.zeros((1, 10))
output = model(test_input)
assert output.shape == (1, 1), "Unexpected output shape"
В этом фрагменте,get_model()Возвращает аtf.kerasМодель ожидает 10 функций. Тест проверяет, что проходное вход дает выходную форму (1,1). Мы также можем проверить числовые выходы или поведение (например,, например,assert output.numpy()[0][0] == expected_value) Чтобы сделать результаты детерминированными, мы можем исправить случайные семена в Tensorflow или Numpy, чтобы тесты были повторяются. Поместив этот тест вtests/каталог позволяет Pytest найти и запустить его автоматически.
Запуск тестов локально может выглядеть как:
pytest --maxfail=1 --disable-warnings -q
Если какой -либо тест не удается, трубопровод должен остановиться, предотвращая упаковку плохой модели. Дженкинс будет записывать эти результаты. Это автоматизированное тестирование гарантирует, что наша модель логика будет подтверждена при каждом изменении, рано улавливая ошибки.
Интеграция трубопровода Дженкинса
Благодаря тому, что на месте мы определяем трубопровод Jenkins, мы определяем трубопровод Jenkins для автоматического запуска. ВJenkinsfile(Хранится в репозитории), мы могли бы написать декларативный трубопровод, как это:
pipeline {
agent any
environment {
IMAGE_NAME = "my-ml-model"
}
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Test') {
steps {
sh 'pytest --maxfail=1 --disable-warnings -q'
}
}
stage('Build Docker') {
steps {
sh 'docker build -t $IMAGE_NAME:$BUILD_NUMBER .'
}
}
stage('Push Docker') {
steps {
// Assuming Docker Hub login is configured
sh 'docker push $IMAGE_NAME:$BUILD_NUMBER'
}
}
}
post {
always {
echo 'Pipeline completed.'
}
}
}
В этом Jenkinsfile есть четыре этапа:Проверить(Получить код),Тест(запустить pytest),Построить Docker(создать изображение) иТолкать докер(подталкивать в реестр). АenvironmentБлок определяет переменные, какIMAGE_NAMEПолем Обратите внимание, как мы называем команды Shell сshПолем В реальной установке учетные данные (для хаба Docker или другие инструменты) будут надежно храниться в Дженкинсе, часто как зашифрованные секреты. Этот фрагмент показывает концептуальный поток и необходимые шаги.
Перечисление шагов трубопровода четко:
- Код проверки:Дженкинс вытаскивает последний код из GIT (запускаемый Commit или WebHook).
- Запустите тесты:Выполнять
pytestВ рабочем пространстве Дженкинса (с установленными зависимостями). - Строите изображение:Если тесты проходят, создайте изображение Docker, содержащее код и модель.
- Push -изображение:Необязательно, нажмите на это изображение в реестр Docker для развертывания.
Наконец, каждый этап может быть визуализирован как простой поток:
[ Git Commit ] -> [ Jenkins CI ] -> [ Tests & Validation ] -> [ Docker Build ] -> [ Registry/Deploy ]
Этот автоматический поток означает, что любое изменение кода запускает трубопровод для запуска. Это вызывает ошибки на раннем этапе и гарантирует, что только проверенные модели приходят к развертыванию.
Заключение
Комбинируя Дженкинс и Докер, мы создаем надежный конвейер CI/CD для науки о данных. Docker гарантирует, что точная среда (операционная система, версия Python и библиотеки) была последовательной и воспроизводимой. Дженкинс организует рабочий процесс, автоматически запускаю тесты и создавая изображения на каждом коммите. Это делает разработку модели более надежным: каждое изменение проверяется в изоляции, а результаты повторяются. Команды, работающие с Python и Tensorflow, получают выгоду от этой автоматизации, потому что она уменьшает ручные шаги и человеческую ошибку. Например, слияние новой функции обработки данных или настройка гиперпараметров пройдет одни и те же тесты, поддерживая всех синхронизации.
С CI/CD на месте, команды могут поставлять модели быстрее и с большей уверенностью. Каждое изменение кода запускает одну и ту же проверенную последовательность тестов и сборки, поэтому ошибки попадают немедленно. Jenkins предоставляет журналы и панели мониторинга для каждого запуска, что позволяет легко увидеть, что удалось или не удалось. Этот подход масштабируется по мере роста проекта, помогая поддерживать постоянный и заслуживающий доверия процесс развертывания. В конце концов, ученые данных могут больше сосредоточиться на улучшении производительности модели и меньше на деталях развертывания. В целом, эта автоматизация освобождает команды данных для быстрого итерации на моделях, не беспокоясь о проблемах развертывания.
Оригинал