Какие по сложности CI/CD пайплайны вам приходилось писать?

Я работал с пайплайнами разной степени сложности, от простых до комплексных, в основном на GitLab CI и GitHub Actions.

1. Базовые пайплайны для монолитов:

   • Стандартные этапы: сборка (build), статический анализ кода (linter, SonarQube), запуск юнит-тестов, сборка Docker-образа, деплой в staging-окружение.

     
     # GitLab CI .gitlab-ci.yml (схематично)
     stages:
     - test
     - build
     - deploy

   unit-test: stage: test script:

   • npm test

   build-image: stage: build script:

   • docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
   • docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

2. Продвинутые пайплайны для микросервисов:

   • Параллельная сборка: Запуск сборки и тестов для нескольких независимых сервисов одновременно для ускорения.
   • Канареечный деплой (Canary): Автоматическое развертывание новой версии на небольшой процент продакшен-трафика с последующим анализом метрик (задержка, ошибки) в Prometheus/Grafana. При ухудшении показателей — автоматический откат.
   • Динамические окружения: Создание временного полноценного окружения (namespace в Kubernetes) для каждого merge request с помощью Terraform/Helm, чтобы тестировать фичу в изоляции, и последующий его удаление.

3. Сложные пайплайны с compliance и безопасностью:

   • Этап безопасности (DevSecOps): Интеграция сканирования уязвимостей в образах (Trivy), зависимостей (OWASP Dependency-Check), SAST-анализ.
   • Артефактные реестры и SBOM: Генерация Software Bill of Materials (SBOM) с помощью Syft и его проверка перед деплоем в продакшен.
   • Ручные approval-гейты: Обязательное подтверждение деплоя в прод ответственным лицом (team lead, менеджер).
   • Гибридная инфраструктура: Сценарии, где часть сервисов деплоится в облако (AWS EKS), а часть — в on-premise Kubernetes кластер.