Ответ
На моём последнем проекте мы использовали стратегию GitFlow в сочетании с Continuous Delivery (CD). Моя роль как QA-инженера была интегрирована в каждый этап.
Основные ветки и процесс:
main/master: Содержит только стабильный, готовый к продакшену код. Каждый коммит сюда — это потенциальный релиз.develop: Ветка для интеграции новых фич. Все feature-ветки мержатся сюда после код-ревью и успешного прохождения пайплайна CI.- *Feature-ветки (`feature/
):** Создаются отdevelop` для каждой новой задачи. Я писал и запускал автоматизированные тесты (API, unit) как часть пайплайна для этих веток.
Процесс подготовки релиза:
- Когда
developнакапливала достаточный для релиза функционал, от неё создавалась ветка *`release/** (например,release/v1.2.0`). - В этой ветке фокусировались только на исправлении багов, доработке документации и финальном тестировании. Новая функциональность туда не добавлялась.
- Я проводил регрессионное и smoke-тестирование на среде, развёрнутой с этой ветки. Все найденные баги фиксились непосредственно в
release/*. - После стабилизации,
release/*мержилась вmain(с тегом версии) и обратно вdevelop.
Деплой: Развёртывание из main в продакшен было автоматизировано через CD-пайплайн. Мы использовали стратегию canary-релиза для критичных сервисов, чтобы сначала выкатить новую версию на небольшой процент трафика, а я в это время мониторил метрики и логи на предмет аномалий.
Горячие исправления: Для срочных багов в продакшене создавались ветки hotfix/* от main. После быстрого цикла разработки и тестирования (фокус на исправлении и регрессии) они мержились и в main, и в develop.
