Какую ветку используете для наката изменений на контур «дев» и «тест»?

Стратегия развертывания в Dev и Test контурах

В современных CI/CD-практиках для развертывания в контуры «дев» (development) и «тест» (test) мы используем подход, основанный на ветке git, которая служит единым источником истины для этих этапов. Конкретный выбор ветки зависит от принятой в команде модели Git-воркфлоу, но в большинстве случаев это либо ветка develop, либо ветка main/master, с дополнениями.

Основные модели и используемые ветки

1. Git Flow (классический):

    *   **Ветка для Dev-контура:** `develop`. Это основная ветка, куда сливаются все фичи (`feature/*`) и где ведется активная разработка. Сборка и деплой на Dev-сервер обычно запускаются автоматически при каждом пуше или мерже в `develop`.
    *   **Ветка для Test-контура:** Также `develop`. Тестовый контур (часто называемый staging/pre-production) питается из той же ветки. Однако для стабилизации и проведения регрессионного тестирования перед выпуском в прод иногда создается ветка `release/*` от `develop`. В этом случае Test-контур может временно переключаться на сборку из этой релизной ветки.

```bash
# Пример процесса в Git Flow
# 1. Разработка ведется в feature-ветках
git checkout -b feature/new-auth develop
# 2. По завершении - merge в develop (запускается pipeline на Dev)
git checkout develop
git merge --no-ff feature/new-auth
# 3. Когда develop стабильна - создаем release-ветку (может деплоиться на Test)
git checkout -b release/1.2.0 develop
# Деплой на Test из release/1.2.0
```

2. GitHub Flow / Trunk-Based Development (упрощенный):

    *   **Ветка для Dev-контура:** `main` (или `trunk`). Все изменения через пулл-реквесты сливаются напрямую в основную ветку. Каждый мерж в `main` автоматически запускает сборку и деплой на Dev,

    *   **Ветка для Test-sm контура:** Как правило, также `main`. Для тестирования используется либо та же сборка, что и для Dev (развернутая на отдельном стенде), либо создается отдельный артефакт (docker-образ) с тегом, соответствующим хешу коммита в `main`, и он деплоится на Test.

```yaml
# Пример секции в GitLab CI/CD .gitlab-ci.yml для Trunk-Based
stages:
  - build
  - deploy_dev
  - deploy_test

build_image:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
  only:
    - main  # Сборка происходит только при изменениях в main

deploy_to_dev:
  stage: deploy_dev
  script:
    - kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -n dev
  only:
    - main

deploy_to_test:
  stage: deploy_test
  script:
    - kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -n test
  when: manual  # Деплой на Test часто требует ручного подтверждения
  only:
    - main
```

Ключевые принципы и детали реализации

• Автоматизация: Вне зависимости от выбранной ветки, процесс деплоя на Dev максимально автоматизирован. Изменение в целевой ветке (develop или main) через вебхук запускает CI/CD пайплайн, который строит артефакт и развертывает его.
• Идемпотентность и артефакты: Мы строго следуем принципу: один коммит — один неизменяемый артефакт (чаще всего Docker-образ). Один и тот же образ, собранный на этапе build, последовательно продвигается по контурам (Dev -> Test -> Prod). Это гарантирует, что в прод попадает ровно то, что было протестировано.
• Изоляция Test-контура: Несмотря на то, что ветка может быть общей, сам Test1-контур (интеграционный, UAT, нагрузочный) физически и логически изолирован от Dev. Он максимально приближен к продовой среде по конфигурации, данным и масштабу.
• Тегирование и версионирование: Для сборок, попавших на Test, мы часто применяем семантическое тегирование (например, 1.2.0-rc.1). Это позволяет однозначно идентифицировать, что именно тестируется.
• Feature Flags: Для управления функциональностью, особенно когда несколько команд работают в одной ветке, мы активно используем Feature Flags (функциональные флаги). Это позволяет мержить код в main/develop раньше, но включать его только на определенных контурах или для конкретных пользователей.

Вывод

Таким образом, прямой ответ на вопрос: в качестве ветки для наката на «дев» и «тест» мы используем либо develop (в классическом Git Flow), либо main (в Trunk-Based Development). Однако критически важным является не название ветки, а выстроенный вокруг нее процесс: автоматизированный пайплайн, использование неизменяемых артефактов, изоляция сред и инструменты для безопасного и постепенного внедрения изменений.