Расскажите процесс, каким образом фича доходит до релиза

В нашей команде процесс построен вокруг CI/CD и выглядит так:

1. Разработка:

• Задача создается в Jira. Разработчик создает Git-ветку от main, пишет код и тесты.
• Каждый коммит в ветку запускает CI-пайплайн (линтеры, unit-тесты).

2. Интеграция и проверка:

• Создается Pull Request (PR). После ревью кода и успешного прохождения всех CI-стадий (включая интеграционные тесты), PR мержится в main.
• Слияние в main автоматически запускает сборку Docker-образа, его сканирование на уязвимости (Trivy) и публикацию в Container Registry (например, ECR).

3. Деплой в staging:

• Образ автоматически деплоится в staging-окружение (Kubernetes namespace staging) через Helm.
• Запускается пайплайн e2e-тестов. QA команда проводиет ручное тестирование.

4. Релиз в production:

• Когда фича готова, мы создаем Git-тег (например, v1.2.3). Это триггер для production-пайплайна.
• Деплой контролируемый: Мы используем стратегию canary-развертывания. Сначала трафик направляется на 10% подов с новой версией, анализируются метрики (латентность, ошибки) в Grafana и логи в Loki. Если все в порядке, постепенно накатываем на 100%.
• Вся конфигурация деплоя (Helm values, ресурсы) хранится как код в том же репозитории.

5. Пострелизный мониторинг:

• После деплоя мы следим за алертами из Prometheus и дашбордами. Настроены SLO-алерты, например, на доступность сервиса ниже 99.9%.

Пример ключевой стадии в .gitlab-ci.yml:

deploy_to_production:
  stage: deploy
  only:
    - tags # Запускается ТОЛЬКО при создании тега
  script:
    - helm upgrade --install my-app ./charts/my-app 
        --namespace production 
        --values ./charts/my-app/values/prod.yaml 
        --set image.tag="$CI_COMMIT_TAG" 
        --wait