Какая последовательность частей в pipeline CI/CD?

Общая последовательность этапов в CI/CD Pipeline

Типичный CI/CD pipeline — это автоматизированная последовательность этапов, через которые проходит код от коммита до развертывания в продакшен. Хотя конкретная реализация зависит от инструментов (Jenkins, GitLab CI, GitHub Actions, Azure DevOps) и методологии (GitOps, trunk-based development), общая логика остается похожей. Pipeline можно разделить на две крупные фазы: Continuous Integration (CI) и Continuous Delivery/Deployment (CD).

1. Фаза Continuous Integration (Непрерывная интеграция)

Цель этой фазы — проверить качество и стабильность нового кода, прежде чем он будет объединен с основной веткой.

• Сборка (Build): Это начальный и обязательный этап. Система забирает исходный код из репозитория (обычно по триггеру на push в определенную ветку, например, main или develop), устанавливает зависимости и компилирует приложение (если необходимо).

  # Пример для Java-проекта (Maven)
  mvn clean compile
  # Пример для Node.js
  npm install
  

• Статический анализ кода (Static Code Analysis): Проверка кода без его запуска. Сюда входят:

    *   **Линтинг** (ESLint, Pylint, Checkstyle) — проверка стиля и выявление потенциальных ошибок.
    *   **Анализ безопасности** (SAST — Static Application Security Testing, например, SonarQube, Snyk Code) — поиск уязвимостей в коде.
    *   **Проверка уязвимостей зависимостей** (OWASP Dependency-Check).

• Тестирование (Testing): Выполняется набор автоматизированных тестов, обычно в порядке возрастания стоимости выполнения:

    *   **Модульные тесты (Unit Tests):** Проверка отдельных функций или классов. Выполняются быстро и изолированно.

    ```bash
    npm test
    pytest
    go test ./...
    ```

    *   **Интеграционные тесты (Integration Tests):** Проверка взаимодействия между модулями, сервисами или с внешними зависимостями (БД, API).
    *   **Тестирование сборки (Build Verification Tests):** Минимальный набор тестов для подтверждения, что сборка работает.

• Сборка артефакта (Artifact Build): Если все проверки пройдены, создается готовый к развертыванию артефакт. Это может быть Docker-образ, JAR/WAR-файл, бинарник или архив. Артефакт помечается уникальной версией (тег, хэш коммита) и загружается в реестр (Nexus, Artifactory, Docker Hub, ECR).

  # Пример сборки Docker-образа
  docker build -t my-app:${CI_COMMIT_SHA} .
  docker push my-registry.com/my-app:${CI_COMMIT_SHA}
  

Важный рубеж: Успешное прохождение фазы CI часто является условием для создания Pull/Merge Request или для автоматического слияния кода в основную ветку. Это "валидный билет" в фазу CD.

2. Фаза Continuous Delivery/Deployment (Непрерывная доставка/развертывание)

Цель — доставить проверенный артефакт в целевое окружение безопасным и контролируемым способом.

• Развертывание в промежуточное окружение (Deploy to Staging): Артефакт развертывается в среду, максимально приближенную к продакшену. Здесь происходит:

    *   **Настройка инфраструктуры** (если используется Infrastructure as Code, например, Terraform).
    *   **Применение конфигураций** (Helm, Ansible, Kubernetes manifests).

```yaml
# Пример деплоя в Kubernetes
kubectl set image deployment/my-app app=my-registry.com/my-app:${CI_COMMIT_SHA} -n staging
```

• Всестороннее тестирование в staging:

    *   **Тесты производительности (Performance/Load Tests):** Использование инструментов вроде JMeter или k6.
    *   **Тестирование безопасности (DAST):** Динамический анализ запущенного приложения.
    *   **Тестирование на соответствие требованиям (Acceptance/E2E Tests):** Автоматические сценарии, имитирующие действия пользователя (Selenium, Cypress).
    *   **Ручное тестирование** (если требуется) QA-инженерами или продукт-менеджерами.

• Развертывание в продакшен (Deploy to Production): Ключевое различие между Continuous Delivery и Continuous Deployment.

    *   При **Continuous Delivery** развертывание в продакшен инициируется **вручную** (кнопка "деплой") после одобрения.
    *   При **Continuous Deployment** этот этап происходит **полностью автоматически** после успешного прохождения всех предыдущих стадий.
    *   Часто используются стратегии для минимизации рисков:
        *   **Canary-развертывание:** Постепенный rollout трафика на новую версию (5% -> 50% -> 100%).
        *   **Blue-Green:** Две идентичные среды переключаются через смену роутера.
        *   **Feature Flags:** Включение функциональности через конфигурацию без деплоя нового кода.

• Пост-продакшен валидация и мониторинг:

    *   **Smoke-тесты в prod:** Быстрая проверка работоспособности ключевых функций уже в бою.
    *   **Мониторинг метрик:** Наблюдение за ключевыми показателями (латентность, ошибки, нагрузка CPU) через Grafana, Prometheus, APM-инструменты.
    *   **Логирование и алертинг:** Настройка алертов на аномалии (например, рост 5xx ошибок).

Итоговая последовательность (упрощенный вид):

1. Триггер (push в репо / merge request).
2. Fetch & Build (получение кода и сборка).
3. Статический анализ и линтинг.
4. Запуск автоматических тестов (Unit -> Integration).
5. Сборка и публикация артефакта (Docker image).
6. Деплой в staging-окружение.
7. Запуск расширенных тестов в staging (E2E, нагрузка).
8. (Опционально) Ручное одобрение.
9. Деплой в production-окружение (авто или ручной).
10. Пост-деплой валидация и мониторинг.

Важное замечание: Современные подходы, такие как GitOps, меняют эту последовательность. Вместо "push-модели" (pipeline запускает деплой) используется "pull-модель": агент в кластере (например, ArgoCD) постоянно сравнивает желаемое состояние (описанное в Git-репозитории) с фактическим и автоматически приводит их в соответствие. В этом случае pipeline заканчивается на обновлении конфигурационного репозитория, а сам деплой становится асинхронным оператором, управляемым Git.