Ответ
В нашем GitLab CI пайплайне для микросервиса на Go стадии выстроены по принципу "fail fast" и постепенного продвижения артефакта по окружениям.
stages:
- validate # Быстрые проверки
- test # Различные тесты
- build # Создание артефактов
- security # Проверки безопасности
- deploy # Развертывание
Детализация стадий:
-
.validate:lint: Запускgolangci-lintдля проверки стиля и простых ошибок.format: Проверка, что код отформатированgo fmt.terraform_validate: Для инфраструктурного кода в том же репозитории — проверка синтаксиса Terraform.
-
.test:unit: Запуск модульных тестов (go test ./...) с измерением покрытия. Результаты отправляются в SonarQube.integration: Запуск интеграционных тестов против тестовой базы данных (Testcontainers).
-
.build:docker_build: Сборка multi-stage Docker-образа. Тегируем его как$CI_COMMIT_SHA.trivy_scan: Сканирование образа на уязвимости (Trivy). Критические уязвимости fail-ят пайплайн.push_to_registry: Пуш образа в私有ный container registry (GitLab Container Registry).
-
.security(параллельно с deploy to staging):sast: Статический анализ безопасности кода (GitLab SAST).dependency_scan: Проверка зависимостей (Go mod) на известные уязвимости.
-
.deploy:deploy_to_staging: Автоматический деплой в staging-кластер Kubernetes с помощьюkubectlили Helm. Используетсяimage: $CI_COMMIT_SHA.e2e_tests: Запуск набора end-to-end тестов (например, через Postman/Newman) против staging.manual_production: Ручной gate. После успеха всех предыдущих стадий и approval тимлида/менеджера запускается деплой в production.deploy_to_production: Деплой с blue-green стратегией через ArgoCD. После переключения трафика запускаются smoke-тесты.notify: Отправка уведомления в Slack-канал о успешном или неудачном деплое.
Ключевой принцип: артефакт (Docker-образ), собранный на стадии build, проходит все последующие проверки неизменным и только в конце разворачивается в prod.