Когда следует использовать mvn release в жизненном цикле проекта?

Question

Чтобы прояснить вопрос:

• Я ищу признанные передовые практики или анализ известных практик за / против
• по жизненному циклу проекта. Я имею в виду: развертывание доИнтеграция, интеграция, QA, preprod и prod environment.

Для некоторого контекста: наш проект развертывается на интеграцию и QA каждую неделю, поэтому мы создаем новую версию для каждого развертывания интеграции, но это не такхорошо чувстовать.Это приводит к обновлению всех poms каждую неделю, нарушая зависимости уровня dev, заставляя каждого dev обновлять свои конфигурации eclipse.У нас большие рабочие пространства, и затмение не так хорошо справляется с обновлениями, поэтому тратится много времени впустую.

Я не слишком знаком с соглашениями о выпуске maven и не смог найти те, которые касаются точкижизненный цикл приложения при использовании mvn release.

Если шаблон, который мы используем сейчас, принят / исправлен / установлен, у меня возникнет другой вопрос:)

Answer 1

Подход, который я использую, чтобы избежать проблемы обновления зависимостей уровня разработки Eclipse, заключается в том, чтобы оставить номер версии соответствующей магистрали или ветви неизменным до тех пор, пока выпуск не станет значительным. Таким образом, вы можете правильно помечать / создавать версии релизов для QA и т. Д., Чтобы вы могли отслеживать проблемы в прошлом, но не требовать разработчиков для обновления зависимостей. Чтобы добиться этого, я использую следующую команду, но переопределяю номера версий, чтобы получить желаемый номер выпуска, но повторно вводю текущую версию снимка в качестве новой версии снимка:

mvn release: prepare -DautoVersionSubmodules = true

P.S. У меня есть диаграмма, которая демонстрирует это, но, к сожалению, недостаточно прав на этом форуме, чтобы прикрепить его. Я с радостью предоставлю это, если кто-то может облегчить прикрепление.

P.P.S Может быть, сейчас ...

Обратите внимание также на поддержку раннего ветвления (2.1) и позднего ветвления (2.2).

Answer 2

В списке пользователей maven (в котором я участвую) продолжается обсуждение, которое кажется актуальным.По сути, мы обсуждаем, как избежать всего того редактирования POM, которое должно выполняться при вырезании ветки (релиз или функция).Плагин релиза может сделать редактирование для вас, когда вы создаете ветку релиза, но он не помогает с ветвями функций, которые необходимо реинтегрировать позже.Кроме того, все, что редактирование POM вызывает ненужную боль, когда вы выполняете слияния, либо слияния rebase из транка, либо реинтеграции в транк.

Идея, обсуждаемая там, основана на том, что подходящее место для записи номеров версий артефактовнаходится в инструменте SCM, а не в POM.По сути, maven должен иметь возможность получить номер версии артефакта из фактического тега или ветви SCM, с которой связана рабочая область.

Обратите внимание, что пока не существует полного решения из-за некоторых проблем, все еще ожидающих решения Maven.средство отслеживания ошибок (например, MNG-2971 ).Но это уже проблемы с большим количеством голосов, и я уверен, что они скоро будут исправлены.

Answer 3

В прошлом я использовал собственную схему нумерации: http://wiki.secondlife.com/wiki/Codeticket_Service

Сейчас я нахожусь в ситуации, когда мне нужно снова подумать о maven, и я испытываю желание повторно использовать схему codeticket для генерации номеров версий / номеров сборок и применения их через плагин релиза, но без проверка файлов pom обратно в . Зарегистрированные файлы pom сохранят номера версий SNAPSHOT.

Для тех, кому небезразличны воспроизводимые сборки, вы можете включить измененный файл POM в свой результат сборки. Лично меня больше интересует отслеживание артефактов сборки и обеспечение того, чтобы те же самые биты, которые были протестированы, в конечном итоге были выпущены, поэтому моя забота о воспроизведении сборок несколько менее религиозна, чем у большинства ( См. Здесь ).

Answer 4

[Не совсем ответ, но лучшее, что у меня есть ...]

Относится к MNG-624 .

В зависимости от того, сколько у вас проектов, может возникнуть проблема даже в вашей системе контроля версий.

Кто-нибудь использует независимую схему нумерации со снимками Maven, чтобы избежать изменения номера версии? Теоретически, вы можете делать то же, что и без Maven, - использовать какую-то внутреннюю систему нумерации для еженедельные сборки. Сборки будут развернуты в разных хранилищах в соответствии с рабочим процессом; вам понадобятся отдельные репозитории для dev, QA, возможно, одно для промежуточного тестирования. Когда вы закончите выпускать кандидатов, начните использовать релизы без снимков. Я просто оцениваю Maven, хотя - У меня нет опыта в этом .

В некоторой документации Nexus (для версии Professional) рассказывается о том, как выполнять сборку, что может быть актуально.

Answer 5

В нашем магазине все наши POM в SVN имеют <version>9999-SNAPSHOT</version> (для их собственной версии, а также для внутренних зависимостей). Это никогда не меняется.

Во время сборки у нас есть простой муравей build.xml, который принимает номер версии (установленный вне maven) в качестве параметра -Dversion=... и просто делает:

<replace includes="**/pom.xml" token="9999-SNAPSHOT" value="${version}"/> <artifact:mvn ... />

Это изменение является локальным для рабочей копии процесса сборки - оно никогда не регистрируется для контроля версий.

Таким образом, все сборки выпуска имеют «реальный» номер версии, но фактически dev никогда не имеет дело с номерами версий.

Вышесказанное, как вы говорите в своем вопросе, категорически не является Правильным способом сделать это, но оно хорошо сработало для нас в течение ~ 9 месяцев с тех пор, как мы приняли maven. У нас есть десятки модулей maven, каждый из которых продвигается в пошаговом режиме к процессу QA / release.

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