Проблемы с выпуском Maven (любая альтернатива плагину релиза)

Question

Я работаю с Maven последние 2 месяца. Я думаю, что понимаю это достаточно, но пока не уверен :) Я получил сборку Snapshot, установил и развернул ее в репозитории нашей команды.

Таким образом, план состоит в том, чтобы использовать сборки Snapshot для сред Dev и, как только он станет стабильным, скажите команде QA использовать его для QA, и как только QA примет сборку, продвиньте ту же сборку в производство.

Мое требование, если сборка снимка будет признана удачной. Я хочу точные биты на производстве. Если я использую плагин релиза, проблема помечается, перекомпилирует источники, проверяет тег и разворачивает его (удаление SNAPSHOT из строки версии в процессе). Проблема в том, что я не могу гарантировать, что он имеет те же биты, что и сборка Snapshot, принятая QA.

Кроме того, я считаю излишним отмечать сборку, потому что Jar manifest имеет ревизию SVN. Поэтому я всегда могу вернуться к этой версии SVN, чтобы отследить сборку из Jar-артефакта Maven.

Итак, мой вопрос: есть ли простой способ продвинуть сборку снимка, которая признана приемлемой для команды QA как есть?

Answer 1

Я тоже исследую эту проблему.Я заядлый пользователь Maven, и я все еще бьюсь головой об стену с помощью плагина релиза (особенно при использовании с Mercurial).

Вот некоторые дополнительные, соответствующие ссылки, с которыми я столкнулся:

• Почему я никогда не использую плагин релиза Maven
• Выпуски Maven на стероидах: плагин релиза Adios!
• Избавьтесь от вашего утомительного и подверженного ошибкам процесса выпуска

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

Мы думаем о переходе к более простому подходу, используя наши собственные сценарии для управления процессом, используя Maven для обновления номеров версий (например, mvn versions:set -DnewVersion=1.1.0), но реализуя наш собственный рабочий процесс ветвления / тегирования / фиксации.

Answer 2

Вы не можете иметь «одинаковые биты», если используете снимки. Вы можете иметь биты, построенные из одного и того же источника. Используйте плагин build-number-plugin для записи ревизии исходного кода в сборку. Когда QA это понравится, пометьте эту версию и сделайте ветку. Затем вручную установите номер версии для нужной версии выпуска.

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

Вам нужно использовать постановку релиза. Запустите плагин релиза, чтобы создать реальный релиз с тегом, но с артефактами, заключенными в тюрьму в промежуточной зоне (через Nexus Pro, следующий выпуск Archiva или использование altDeploymentUrl). Попросите QA протестировать версию области подготовки. если они благословят это, продвиньте эти биты в официальную область выпуска. Если QA звонит, удалите метку и удалите область подготовки.

Таким образом, вы завершаете тестирование тех самых битов, которые вы себе представляете.

Answer 3

Здесь есть замечательный блог, описывающий довольно простую альтернативу использованию плагина релиза maven. Мы будем использовать адаптацию этой стратегии в нашем проекте, это позволит избежать многих проблем и сложности плагина релиза.

Maven релизы на стероидах

Answer 4

1. Вы можете открыть ветку сразу после отправки снимка в QA.
2. Блокировка основной ветки / ствола, которая была отправлена ​​в QA.
3. Если принято, используйте плагин релиза напринятая ветвь / ствол.
4. Обновите pom на главной до следующей SNAPSHOT и объедините с открытой веткой, если на ней что-то было добавлено.

Answer 5

Один из подходов - позволить серверу CI вместе с вашим двоичным репозиторием.Вы можете полностью пропустить maven-release-plugin.

Вот пример того, как это выполняется с помощью Плагин TeamCity Artifactory - Управление выпуском .

Я уверен, чтотакие же возможности существуют, если вы используете другой CI-сервер, такой как Jenkins, а также вместе с другим двоичным репозиторием, таким как Nexus.