Релиз Maven через Hudson

Question

Я настраиваю Hudson на использование плагина пакетной задачи для создания релизов maven для нашего внутреннего репозитория.Я делаю это через:

mvn --batch-mode release:prepare
mvn --batch-mode release:perform

Меня интересуют другие методы, которые использовали люди, а также плюсы и минусы этих методов.Кроме того, любые ошибки, с которыми сталкивались люди.

Answer 1

Я склонен всегда делать релизы вручную по нескольким причинам.Во-первых, если вам нужно выполнить откат, это проще, когда вы можете вернуться к исходному местоположению выпуска и сделать это.Во-вторых, потому что вам нужно разрешить все зависимости от моментальных снимков как часть процесса.

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

Тем не менее, у нас есть специальная машина (в Sonatype это просто виртуальная машина), настроенная только для сборок.Это сделано для того, чтобы гарантировать отсутствие изменений среды, которые могли бы случайно повлиять на сборку (например, изменение jdk).Это также облегчает любому пользователю процесс выпуска, потому что он всегда готов к работе.

Answer 2

Недавно мое внимание привлек плагин m2release.Показался милым.Хотя мне бы хотелось, чтобы процесс моего выпуска был полностью «без настройки pom».Под этим я подразумеваю, что мы должны предоставить 4 входных параметра для обработки полного выпуска:

1. релизная версия (напр.1.0.0)
2. новая версия разработки (напр.1.0.1-МОМЕНТАЛЬНЫЙ СНИМОК)
3. тег выпуска в SCM (напр.версия -1.0.0 или 1.0.0)
4. базовый путь тега в SCM

Первые 2 имеют приемлемые значения по умолчанию.Версия, натыкающаяся на цифру версии исправления ошибок, меня вполне устраивает.

Номер 4 может быть указан в пом.Это не изменится.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <configuration>
        <tagBase>https://example.com/svn/myProject/releases</tagBase>
    </configuration>
</plugin>

Это третья проблема, которая мешает мне полностью автоматизировать выпуск одним нажатием кнопки.Тег выпуска по умолчанию label не сделает этого за нас, поэтому мы должны указать его:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <configuration>
        <tag>release-${pom.version}</tag>
        <tagBase>https://example.com/svn/myProject/releases</tagBase>
    </configuration>
</plugin>

Теперь, хотя это может быть как раз то, что мне было нужно, в итоге у меня получается тег svn с -SNAPSHOT в конце.:( Итак, я должен передать параметр tag в конфигурации задания Hudson.Более того, я должен менять его для каждого выпуска, который мы делаем ...а это не совсем то, что мне нужно.

---

Итак, в конце концов, наличие проекта типа maven2 в hudson + правильно настроенный плагин m2release hudson + плагин maven release - это основа всего процесса выпуска, который я видел до сих пор.Хотя это и не идеально, это избавило меня от кропотливой работы.

ДЖС.

Answer 3

Я всегда запускал релиз вручную с очевидными плюсами и минусами :-)

Answer 4

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