Как выглядит логика работы хорошего CI/CD?

Архитектура хорошего CI/CD pipeline

Хороший CI/CD — это автоматизированная система доставки кода от разработчика до production с минимальными ошибками и максимальной скоростью. Вот ключевые компоненты логики работы.

1. Continuous Integration (CI) — Автоматическая проверка кода

Когда разработчик делает push в репозиторий, сразу запускаются автоматические проверки:

• Сборка (Build): компилирование кода, установка зависимостей
• Статический анализ: linting, проверка стиля кода (flake8, ruff для Python)
• Юнит-тесты: проверка отдельных функций, target coverage 90%+
• Интеграционные тесты: проверка взаимодействия модулей
• Качество кода: SonarQube, код ривью, проверка на уязвимости

# Пример CI конфига (GitHub Actions)
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run linting
        run: make lint
      - name: Run tests
        run: make test
      - name: Check coverage
        run: pytest --cov=src --cov-fail-under=90

2. Continuous Delivery (CD) — Подготовка к развёртыванию

Если CI прошла успешно, код автоматически подготавливается к продакшену:

• Автоматическая сборка артефактов: Docker image, wheel файлы
• Staging окружение: развёртывание на тестовом серверу, близком к продакшену
• Smoke-тесты: быстрые проверки базовой функциональности
• Готовность к развёртыванию: кнопка нажатия для запуска на prod

3. Continuous Deployment (CD) — Автоматический запуск в продакшен

Освобождение нового функционала без ручного вмешательства:

• Автоматический деплой на production при успешной сборке
• Health checks: проверка, что сервис поднялся корректно
• Мониторинг: отслеживание метрик, логов, ошибок в реальном времени
• Откат (Rollback): автоматический откат при падении метрик

4. Стратегии развёртывания

Blue-Green Deployment:

• Две идентичные среды production (Blue и Green)
• Новый код заливается в неактивную среду
• После тестирования переключают трафик
• Если проблема — быстрый откат

Canary Release:

• 5% трафика идёт на новую версию
• Если метрики стабильны, увеличиваем до 10%, затем 50%, затем 100%
• Позволяет ловить проблемы на малой аудитории

# Пример куска Dockerfile для ML модели
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY src/ /app/src/
EXPOSE 8000
CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8000"]

5. Feedback loop и мониторинг

• Логирование: структурированные логи (JSON) для быстрого анализа
• Метрики: Prometheus, Grafana для отслеживания performance
• Оповещения: Slack/PagerDuty уведомления при критических ошибках
• Обратная связь разработчикам: быстрое сообщение об ошибках в PR

6. Принципы для Data Scientist

Для ML проектов CI/CD должен включать:

• Data validation: проверка качества тренировочных данных
• Model versioning: MLflow/DVC для отслеживания версий моделей
• Performance monitoring: отслеживание drift, accuracy в продакшене
• A/B тестирование: сравнение новой и старой модели на реальных пользователях

Результат

Хороший CI/CD означает, что разработчик может деплоить код в production несколько раз в день с уверенностью, что все проверки пройдены автоматически. Это снижает количество багов в production, ускоряет время разработки и позволяет быстро реагировать на проблемы.