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

Логика эффективного CI/CD-пайплайна строится на принципах полной автоматизации, быстрой обратной связи и безопасного развёртывания. Вот как это выглядит на практике:

Основные этапы пайплайна:

1. Сборка (Build): Компиляция кода и создание артефактов (Docker-образ, jar-файл). Образы помечаются хэшем коммита и пушатся в registry.

   # GitLab CI пример
   build:
     stage: build
     script:
       - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
       - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

2. Тестирование (Test): Запуск автоматических проверок.

   • Юнит-тесты: Быстрая проверка логики.
   • Интеграционные тесты: Проверка взаимодействия с БД, кэшем.
   • Сканирование уязвимостей (SAST/DAST): Инструменты типа Trivy или Snyk.

3. Деплой в staging: Развёртывание артефакта в среду, максимально приближённую к production. Здесь запускаются E2E-тесты и нагрузочное тестирование.

4. Ручное утверждение (Manual Approval): Для production-деплоя часто требуется approve от тимлида или ответственного. Это контрольная точка.

5. Деплой в production: Использование стратегий для минимизации рисков:

   • Blue-Green: Мгновенный переключение трафика между двумя идентичными средами.
   • Canary: Постепенный rollout на небольшой процент пользователей для мониторинга метрик (ошибок, latency).

     # Пример canary-деплоя в Kubernetes с Istio
     kubectl apply -f virtual-service-canary.yaml # Направить 10% трафика на новую версию

6. Пост-деплойные действия: Автоматический сбор метрик, проверка здоровья (health checks) и возможность быстрого отката (rollback) при обнаружении проблем.

Ключевые метрики успешного CI/CD: время от коммита до продакшена (Lead Time), частота деплоев, процент успешных деплоев и время восстановления при сбое (MTTR).