Maven релиз через Гудзон

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

1. версия выпуска (например, 1.0.0)
2. новая версия разработки (например, 1.0.1-SNAPSHOT)
3. тег выпуска в SCM (например, release-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>

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

<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, это Мать всего процесса выпуска, который я видел до сих пор. Хотя это и не идеально, это спасло мне много утомительной работы.

JS.

Answer 3

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

Answer 4

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