Лучшие практики Maven для управления версиями различных веток [разработка, qa/предварительный выпуск]

У меня есть несколько проектов, которые разрабатываются и выпускаются в разных отраслях, а именно: разработка и выпуск. Процесс работает очень хорошо, но, к сожалению, он имеет некоторые недостатки, и мне было интересно, есть ли в моей ситуации более эффективная схема управления версиями.

Основное развитие происходит в ветке разработки (т.е. Subversion trunk, но это не имеет большого значения), когда команда разработчиков фиксирует свои изменения. После сборки и упаковки артефактов, Jenkins развертывает их в maven-хранилище и сервер приложений для интеграции приложений. Это DEVELOPMENT-SNAPSHOT и в основном это ветка функций, содержащая все разработанные функции на одной общей ветке:

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>D.16-SNAPSHOT</version>

Когда одно конкретное изменение бизнеса выполняется и запрашивается командой QA, это одно изменение затем объединяется с ветвью выпуска (ветки/выпуск). Дженкинс развертывает полученный артефакт на сервер приложений QA:

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>R.16-SNAPSHOT</version>

Затем появляется релиз, который происходит через maven-release-плагин в версии версии релиза программного обеспечения (который создает тег обслуживания/ветку для быстрой исправления ошибок). (R.16-SNAPSHOT = > R.16)

Разделы разработки и выпуска в настоящее время версируются как D.16-SNAPSHOT и R.16-SNAPSHOT соответственно. Это позволяет разделить артефакты в репозитории maven, но создает проблему с различными механизмами maven, которые основаны на стандартном стиле управления версиями maven. И это также нарушает управление версиями OSGI.

Теперь, как бы вы назвали артефакты maven и версию maven в такой схеме? Есть ли способ лучше? Может быть, я мог бы внести некоторые изменения в структуры maven, кроме простого изменения схем управления версиями и именованиями? Но мне нужно, чтобы ветки развития и QA (выпуска) разделялись отдельно.

Будет ли разумным альтернативой классификатор "разработки" / "производства" maven?

<groupId>pl.cyfrowypolsat.process-engine</groupId>
<artifactId>process-engine</artifactId>
<version>16-SNAPSHOT</version>
<classifier>D</classifier>

ОТВЕТЫ

Ответ 1

Насколько я знаю, общим расширением имен для артефакта выпуска будет просто имя артефакта без каких-либо вещей, только указанная версия. Развертывание развития имеет одно и то же имя артефакта, но с моментальным снимком.

Например, возьмите twitter4j. Имя артефакта версии выпуска

twitter4j-2.5.5

Снимок их версии разработки

twitter4j-2.6.5-СНАПШОТ

Это соглашение об именах, которое почти все используют и которое распознается большинством инструментов. Например, в моем репозитории Nexus можно указать политику для игнорирования релизов разработки, что в основном означает, что она игнорирует артефакты, содержащие -SNAPSHOT в их имени.

EDIT: К вашему последующему вопросу:

Ну, в зависимости от вашего инструмента построения, вы можете создавать свои снимки, чтобы иметь метку времени или какой-либо другой уникальный идентификатор. Однако я никогда не слышал о том, что какая-либо ветвящаяся логика встроена в имя артефакта, так что непрерывный int-сервер может ее отличить. С точки зрения артефакта это либо релиз, либо SNAPSHOT, я не вижу преимущества вложения большей логики в имя артефакта, просто потому, что ваш Хадсон позволяет вам делать это. Честно говоря, ваш цикл выпуска кажется мне удобным, но для этого вам потребуется небольшая настройка ваших инструментов maven. Если вы не можете жить с этим, я предлагаю вам использовать классификатор вместо того, чтобы полагаться на имя, поскольку всегда проще настраивать сервер интеграции, чем много плагинов, которые полагаются на стандартное соглашение об именах. В заключение я считаю, что вы на правильном пути.

Ответ 2

Я думаю, вы могли бы просто выполнить этот процесс, имея только два типа в отношении maven

  • Снимок (в бессрочном развитии)
  • Releasable (с номером версии, который можно развернуть в репозитории maven или в выпуске выпуска)

Я бы обработал вашу ветку немного по-другому. Если вы посмотрите на модель разработки с итерацией/схваткой, ваш код должен быть освобожден/отправлен в конце итерации/спринте

  • Основная подкадровая версия, где разработчики передают свой код
  • В конце ветки sprint/iteration основная магистраль и называется ее ветвью релиза (не должно быть ветки QA, любой код, который должен быть выпущен, проверяется на качество)
  • Исправления ошибок должны произойти в ветки релиза и периодически сливаться с основной магистралью
  • Таким образом, вы можете продолжать создавать ветки для выпуска, и любые исправления ошибок привязаны к ветке
  • Обязательно убедитесь, что перед созданием новой ветки из основной соединительной линии, она имеет все слияния с предыдущими ветвями

Ответ 3

Плагин релиза от Maven поддерживает ветвление. Похоже, что это работает, если предположить, что ветвь создана для поддержки следующей версии вашего кода.

Лично я более склонен использовать versions плагин и явно задал номера версий проекта Maven.