Кратко и по делу — как я бы выстроил CI/CD для гибридного проекта (часть монолит, часть микросервисы): уровни тестов, инструменты оркестрации релизов и стратегии отката.
1) Общая архитектура конвейера (рекомендация)
- Trunk‑based development + короткие ветки фич/PR.
- Пайплайн на PR: быстрые проверки; пайплайн на merge в основную ветку: полноценный CI → CD.
- Артефакты — immutable (Docker image с тегом = $\text{sha}$ коммита и семантическая версия), хранилище образов (Registry/Nexus/Artifactory).
- GitOps для k8s‑декларации (репозиторий manifests → ArgoCD/Flux) или декларативный CD (Spinnaker/ArgoCD).
2) Уровни тестов и где запускать
- Unit tests — в каждом PR, быстрые, локальные/CI; покрытие компонентов/библиотек.
- Static analysis/SAST — в CI до сборки артефакта.
- Contract tests (consumer-driven contracts) — в CI:
- Consumer запускает contract suite против stub/provider mock;
- Provider выполняет verification подписанного контракта.
- Инструменты: Pact, Spring Cloud Contract.
- Integration tests (component/integration) — на контейнерах/эпhemeral средах в CI: Testcontainers, docker‑compose, kind/minikube. Проверяют взаимодействие сервиса с БД, брокером, внешними адаптерами.
- API/Component tests — в интеграционной среде (preview/staging).
- End‑to‑End / UI tests — на staging (ограниченное количество), инструменты: Cypress, Playwright.
- Performance / Load tests — отдельно на staging/production‑like средах, инструменты: k6, JMeter.
- Security tests (DAST/SCA) — SCA (dependency scan) в CI; DAST в staging.
3) Где и в каком порядке запускать (пример пайплайна)
- PR: lint → unit tests → SAST → build image → image scan → publish snapshot image.
- Merge/main: unit tests → contract tests (consumer+provider verifications) → integration tests (ephemeral env) → push immutable image (stable).
- Deploy to dev/preview → smoke tests → automated integration/E2E → performance/security (по расписанию) → manual/automated promote to staging → preprod acceptance → canary/gradual deploy в prod.
4) Оркестрация релизов — инструменты и паттерны
- GitHub Actions / GitLab CI / Jenkins / CircleCI: CI.
- Kubernetes + Helm/Kustomize для деплоя мc/s.
- GitOps: ArgoCD или Flux — синхронизация k8s манифестов из git (рекомендуется).
- Canary/Progressive delivery: Flagger (для k8s, работает с ArgoCD, uses Prometheus/Datadog for metrics), Spinnaker (многофункциональный, multi‑cloud).
- Blue/Green и Rolling: реализуются через k8s deployments + service routing (Ingress/Service mesh).
- Service mesh (Istio/Linkerd) для продвинутой маршрутизации, A/B, traffic splitting, metrics.
- Tekton для Kubernetes‑native pipeline (если хочется CI/CD в k8s).
5) Стратегии релизов для гибрида монолит + микросервисы
- Независимый релиз микросервисов: CI → canary → promote.
- Монолит: чаще уменьшать размер релизов, использовать feature flags и контракт‑тесты для совместимости.
- Для изменений, которые затрагивают и монолит, и микросервисы — координированный pipeline с «gating»: контракт‑проверка + интеграционные тесты между обеими частями, затем staged deploy.
- Preview/ephemeral environment на каждую фичу/PR для ручного тестирования и QA (Helm + ephemeral namespaces).
6) Стратегии отката и безопасного релиза
- Immutable artifacts: всегда можно быстро вернуть предыдущий image/tag.
- Automated rollback on failure: откат при провале health/readiness checks или при нарушении SLO (ArgoCD/Spinnaker/Flagger может делать автоматические rollbacks).
- Canary + metrics gating: при аномалиях (error rate, latency, custom SLO) откатить трафик на предыдущую версию.
- Blue/Green: мгновенный переключатель трафика на старую версию при проблеме.
- Feature flags: выключить фичу без деплоя (мгновенный «откат» поведения). Рекомендуемые фрэймворки: LaunchDarkly, Unleash, Flagsmith, open source.
- Database migrations: use expand/contract pattern:
- Шаг 1 (expand): добавить совместимые изменения (новые поля/таблицы), деплой кода, dual‑write/dual‑read, backfill.
- Шаг 2 (switch): переключение логики чтения.
- Шаг 3 (contract): удалить старое поле позже.
Никогда не делать destructive миграции в одном релизе без стратегии отката.
- Forward‑only approach если откат БД невозможен: откат через новую миграцию, возвращающую прежнее состояние (предпочтительно).
7) Мониторинг и автоматизация релизного контроля
- Метрики и алерты: Prometheus + Grafana; распределённый трейсинг: Jaeger; логирование: EFK.
- SLO/SLI для автоматического принятия решений по откату.
- Аварийные runbooks + интеграция с PagerDuty/Opsgenie.
8) Практические советы
- Минимизируйте время интеграционных тестов; unit = fast, интеграция = селективна.
- Контракты удерживают совместимость: consumer‑driven для микросервисов.
- Эфемерные среды для интеграции и раннего QA → уменьшают сюрпризы в проде.
- Автоматизируйте промоутинг образов через окружения и используйте immutability + tagging.
- Документируйте rollback procedures и проверяйте их через «fire drills».
Если нужно — дам пример пайплайна (шаги + команды) под конкретные инструменты (GitHub Actions + ArgoCD + Helm + Pact + Flagger).