Какие CI/CD пайплайны были реализованы на вашем последнем проекте?

На последнем микросервисном проекте мы построили многоступенчатую систему доставки на основе GitLab CI/CD и ArgoCD (GitOps).

Структура пайплайнов:

1. Merge Request Pipeline (запускается на каждый push в MR):

   • Стадия validate: Проверка Terraform кода (terraform validate), линтинг Dockerfile (hadolint), проверка Helm-чартов (helm lint).
   • Стадия build: Сборка Docker-образа приложения, тегирование его хэшем коммита.
   • Стадия test:
     • Unit-тесты внутри контейнера.
     • Сканирование образа на уязвимости (Trivy).
     • Статический анализ кода безопасности (Semgrep).
   • Стадия deploy-review: Автоматическое развертывание изменений в изолированный неймспейс Kubernetes (review-<branch-name>) для ручного тестирования. После закрытия MR окружение автоматически уничтожается.

2. Main Branch Pipeline (запускается при мерже в main):

   • Проходит все стадии MR-пайплайна.
   • Стадия push: Пуш собранного образа с тегами latest и $CI_COMMIT_SHA в приватный Container Registry (AWS ECR).
   • Стадия gitops-update: Автоматически обновляет манифесты в GitOps-репозитории, изменяя tag образа в Helm-чарте на новый $CI_COMMIT_SHA. Это триггерит ArgoCD на деплой в staging.

3. Production Deployment:

   • Развертывание в prod было ручным, но однокликовым. После успешных тестов в staging, ответственный нажимал кнопку Promote to Production в ArgoCD, что синхронизировало состояние prod-кластера с версией манифестов, помеченной как стабильная.

Ключевые практики:

• Everything as Code: Конфигурация пайплайна, инфраструктура, манифесты приложений — все хранится в Git.
• Immutable Infrastructure: Для каждого деплоя создается новый уникальный Docker-образ, откат — это деплой предыдущего образа.
• Security Shift Left: Проверки безопасности интегрированы на самых ранних этапах (линтеры, сканеры в CI).