Gitflow Workflow с Maven - когда что строить? - PullRequest
Новая
       10

Gitflow Workflow с Maven - когда что строить?

1 голос
/ 25 марта 2020

Gitflow представляет несколько веток, таких как develop, release, hotfix, а также поощряет функциональные ветки.

В проекте Maven вы обычно создаете SNAPSHOT и выпускаете версии и часто нумеруете их с помощью semanti c, Three-Di git версии.

Было бы разумно максимально автоматизировать процесс сборки, но вопрос заключается в следующем: когда мы должны собирать версию SNAPSHOT, когда следует собирать версия выпуска, когда нам вообще не нужно ничего строить?

Я представляю, что может иметь смысл следующее:

  • Всякий раз, когда ветвь функции объединяется обратно в develop, Сборка SNAPSHOT запускается и развертывается в репозитории Maven.
  • Когда создается ветвь release, запускается сборка выпуска.

Но существует гораздо больше ситуаций:

  • Когда я исправляю ошибки в ветви release (или hotfix), всегда ли я хочу новую сборку релиза?
  • Следует ли при разработке функции использовать эту функцию? филиал? Если да, то как должна называться эта версия (1.2.3-FEATURE1-SNAPSHOT?)?

1 Ответ

3 голосов
/ 25 марта 2020

Давайте начнем с выпусков. Будет ли версия выпущена или нет, будет решено в будущем, когда уже созданный двоичный файл будет развернут в средах TST и проверен. При фиксации или построении вы не можете предсказать, будет ли версия «релизом».

Как только вы откажетесь от этих идей, все станет намного проще. И поскольку вы не можете использовать версии на основе веток для выпусков, какой смысл отличать ветки компонентов от других? Вы также можете забыть о смешении концепций ветвления и управления версиями.

С помощью Continuous Delivery (вы можете заимствовать ее идеи, даже если вы не используете ее в полной мере), любая сборка может потенциально go PRD, таким образом:

  1. Создайте двоичный файл с любым типом версий, который вам нравится. С Maven проще всего придерживаться SNAPSHOT * и никогда не использовать «релиз». Он уникальный, стандартный, у него есть некоторые преимущества с Nexus (политики хранения).
  2. Когда вы будете готовы go к PRD и выбрана версия выпуска - пометьте его как-нибудь. Это может быть задание CI, которое отслеживает все развертывания PRD; или у вас может быть страница со всеми версиями выпуска; или вы можете перенести бинарный файл в другой репозиторий Maven (по-прежнему может иметь тип SNAPSHOT). Последнее удобно, если вы go используете политики хранения для снимков.

Также мы обычно хотим указать, из какого коммита был создан бинарный файл. Вы можете поместить это в двоичный файл (что-то вроде version.properties) во время сборки. Вы даже можете создать конечную точку в своем приложении, которая будет обслуживать эту версию для удобства.

PS: если вы просто хотите следовать советам GitFlow - есть официальная страница для управления версиями. Но у вас будут все проблемы (и даже больше), о которых вы уже упоминали в этом вопросе.

* Maven автоматически разрешает версии SNAPSHOT в метки времени. Но вы на самом деле не можете использовать эту функциональность, потому что временная метка будет отличаться для разных артефактов во время сборки. Если вы хотите сохранить одинаковую версию во всех двоичных файлах сборки, вам нужно сгенерировать и назначить версию метки времени вручную, используя versions:set. Это не сложно, но стоит упомянуть.

...