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

Question

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

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

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

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

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

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

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

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

Будет ли разумной альтернативой классификатор maven по «развитию» / «производству»?

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

Answer 1

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

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

twitter4j-2.5.5

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

twitter4j-2.6.5-SNAPSHOT

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

EDIT: На ваш следующий вопрос:

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

Answer 2

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

1. Снимок (В вечной разработке)
2. Releasable (с номером версии, которую можно развернуть в репозитории maven или в производственной версии)

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

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

Answer 3

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

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