Как вы реализовали логику CI/CD, используя git flow?

Sobes Copilot

Получайте ответы в реальном времени

Ответ от нейросети

sobes.tech AI

Используя Git Flow, логика CI/CD может быть построена следующим образом:

feature ветки: При создании новой фичи или изменении, разработчик работает в отдельной feature ветке, ответвленной от develop. При каждом изменении в этой ветке может запускаться минимальный набор проверок (статический анализ, линтинг).
pull request (PR) / merge request (MR): После завершения работы над фичой, создается PR/MR для слияния feature ветки в develop. Этот триггер запускает полный пайплайн CI:
- сборка проекта
- запуск всех тестов (юнит, интеграционные, приемочные)
- проверка кода на соответствие стандартам (линтинг, форматирование)
- анализ безопасности кода
- сборка артефактов (например, Docker-образов)
develop ветка: Слияние в develop происходит только после успешного прохождения всех проверок в CI и ревью кода. Каждое слияние в develop запускает CD-часть пайплайна:
- развертывание артефактов в среду разработки (Development Environment).
- проведение автоматизированных UI/E2E тестов на развернутой версии.
release ветки: Для подготовки к релизу создается release ветка от develop. На этой ветке проводятся финальные стабилизационные работы и исправления багов. Пайплайн для release веток может включать:
- CI проверки (аналогично develop).
- сборка релизных артефактов.
- развертывание в тестовую/staging среду (Staging Environment) для ручного тестирования и приемочных испытаний.
main / master ветка: После стабилизации release ветка сливается в main (или master) и помечается тегом с номером версии. Слияние в main triggering:
- сборка артефактов для продакшна.
- развертывание в продакшн среду (Production Environment).
hotfix ветки: Для срочных исправлений в продакшне создается hotfix ветка от main. Пайплайн для hotfix веток مشابه релизному:
- CI проверки.
- сборка артефактов hotfix.
- развертывание в staging для проверки.
- развертывание в продакшн после успешной проверки. hotfix ветка также сливается в develop для синхронизации изменений.

Пример структуры пайплайнов на Git Flow:

Git Flow Ветка	Триггер CI/CD	CI Задачи	CD Задачи	Среда Развертывания
`feature/*`	Push в ветку	Линтинг, стат. анализ	Нет (опционально, на тестовом окружении для разработчика)	Нет
`feature/*`	PR/MR в `develop`	Сборка, тесты (юнит, интеграционные), анализ безопасности, сборка артефактов	Нет	Нет
`develop`	Merge PR/MR	-	Развертывание в Dev, UI/E2E тесты	Development
`release/*`	Создание ветки, Push	Сборка, тесты, анализ безопасности, сборка релиз. артефактов	Развертывание в Staging, ручное тестирование, приемочные испытания	Staging
`main`	Merge `release/*`	Сборка прод. артефактов	Развертывание в Production	Production
`hotfix/*`	Создание ветки, Push	Сборка, тесты, анализ безопасности, сборка hotfix артефактов	Развертывание в Staging, ручное тестирование, приемочные испытания, Развертывание в Production	Staging/Production

Использование тегов в Git Flow на ветке main (или master) является триггером для финального этапа CD – развертывания в Production.

# Пример пайплайна в GitLab CI/CD для ветки main
build_deploy_prod:
  only:
    - main@<ваш_путь_к_репозиторию> # Триггер на пуш в main
    - tags                          # Триггер на создание тега
  stage: deploy_prod
  script:
    - echo "Building production artifacts..."
    # Команды для сборки production версии
    - echo "Deploying to production..."
    # Команды для развертывания в production
  environment:
    name: production
    url: https://<адрес_продакшн_среды>
  when: manual # Или on_success, в зависимости от процесса