Стратегия ветвления Gitflow

Question

Прежде всего, я очень хорошо знаю о Gitflow, и стараюсь подтолкнуть мою команду, чтобы полностью следовать ему. Однако операционная команда позволяет выпускать только ту версию приложения, которая сертифицирована QA. Если мы следуем Gitflow, выпускная версия всегда должна поступать из основной ветки, но, поскольку QA тестирует выпускную ветвь, они только сертифицируют кандидатов на выпуск. Для того, чтобы QA сертифицировал мастер-срез, им нужно выполнить еще один регрессионный тест, поэтому они отодвигаются. Все кандидаты на выпуск имеют RC # в версии, которая не является хорошей версией maven по шаблону major.minor.patch.

Мой вопрос: как избежать дополнительного регрессионного теста после слияния релиза с мастером, перед производственным релизом? Любые советы приветствуются. Спасибо

Answer 1

master представляет то, что в настоящее время находится в производстве. В gitflow вы создаете release ветку разработки. QA тогда проверит ветку release. Когда QA выполнено, ветвь release развернута и затем объединена в master.

Не нужно ничего проверять, когда вы объединяете ветку release с master. Это уже было проверено.

Но что важно, когда master обновляется (путем объединения веток релиза), вам также необходимо объединить master в develop. Таким образом, когда вы вырезаете следующую ветку release из develop, вы знаете, что в ней есть весь развернутый код.