Maven и git-flow, стратегия версий для кандидатов на релиз

Question

Мы пытаемся применить модель git-flow для maven проектов.

Мы используем develop а также feature/XXX ветви для работы -SNAPSHOT версионные артефакты, которые развернуты в нашем DEV а также TST сред.

Когда приложения "готовы", у нас есть "релиз кандидатов": код выдвигается на release ветка, мы редактируем пом, чтобы обновить версию (заменить -SNAPSHOT от -RC1), эта версия создается и хранится в менеджере хранилища, а затем развертывается на нашем UAT окр.

Если некоторые исправления необходимы, мы создаем другие -RCx версии в том же release В филиале эти артефакты архивируются в менеджере хранилища и развертываются на UAT окр. Таким образом, мы можем точно отследить исправление ошибки в разных версиях.

Когда -RCx версия утверждена, release ветвь подталкивается к masterПом обновил, чтобы удалить -RCx, собран и хранится в менеджере хранилища перед развертыванием в PROD окр.

Но при таком способе работы исполняемые файлы в PROD И в UAT не являются строго одинаковыми: POMs отличаются в 2 WAR, из-за <version> тег. И это не очень хорошая практика.

Если я правильно понял модель git-flow, то "окончательный" номер версии (без -RCx) должен быть установлен при создании release ветвь, и та же версия "жива", пока эта ветвь не будет передана master, право? В этом случае:

• Мы теряем информацию о том, какая версия приложения действительно развернута в UAT (как мы потеряли -RCx идентификатор, мы можем не знать, содержит ли развернутая версия последние исправления или развернута более старая версия...)
• В диспетчере хранилища мы не можем знать, был ли создан артефакт из release филиал или из master, так как больше нет изменения номера версии при нажатии feature разветвляться в master,

Что лучше? Каковы плюсы / минусы этих 2 способов сделать? (Не одинаковые двоичные файлы в разных envs -vs-, не имеющие четко идентифицированных кандидатов на выпуск.)

Как вы (или вы) управляете Release Candidates с проектом Maven в модели git-flow?

Answer 1

Я рекомендую добавить номер версии в вашу стратегию управления версиями. Номер редакции устанавливается равным 0 при запуске ветки релиза, а затем увеличивается с каждым исправлением. После завершения тестирования разверните точную версию, которая проверяла тестирование, в производство. Такой подход обеспечивает отслеживаемость для каждой версии, поддерживает согласованность версий в разных средах и устраняет необходимость в новой сборке, которая просто формализуется вокруг номера версии. Точно такие же двоичные файлы, которые проверены в вашей тестовой среде, могут быть развернуты в рабочей среде.

Я использовал эту стратегию для нескольких производственных приложений и не было никаких проблем.