Опиши процесс от момента, когда разработчик запушил код, до его попадания в продакшн

В моей практике типичный пайплайн для микросервиса на Kubernetes выглядит так:

1. Push в репозиторий: Разработчик создает feature-ветку и пушит изменения. Это триггерит запуск CI-стадии.
2. CI (Continuous Integration):
   • Сборка образа: docker build -t registry.company.com/app:$CI_COMMIT_SHA .
   • Статический анализ кода: Запускаем sonarqube-scanner и gosec для проверки качества и безопасности Go-кода.
   • Unit-тесты: go test ./... -v -cover с генерацией отчета о покрытии.
   • Сканирование образа на уязвимости: trivy image --exit-code 1 registry.company.com/app:$CI_COMMIT_SHA.
   • Пуш образа в registry: Только если все предыдущие шаги успешны.
3. Code Review: Создается Merge Request (GitLab) / Pull Request (GitHub). После апрува от тимлида и успешного прохождения CI, код мержится в main.
4. CD (Continuous Deployment): Мерж в main запускает CD-стадию:
   • Деплой в staging: kubectl -n staging set image deployment/app app=registry.company.com/app:$CI_COMMIT_SHA. Параллельно запускаются интеграционные тесты через Postman/Newman.
   • Канареечный деплой в prod: Используем Flagger для постепенного переноса трафика (5% -> 25% -> 100%) на новый Pod, основываясь на метриках из Prometheus (латенткость, error rate).
   • Роллбэк: При срабатывании алерта в Grafana Flagger автоматически откатывает релиз.

Пример ключевого этапа из .gitlab-ci.yml:

deploy_canary:
  stage: deploy
  script:
    - kubectl apply -f k8s/canary-release.yaml
  only:
    - main