Автоматизация рутины при выпуске релизов с Maven

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

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

Для облегчения релизов воспользуйтесь плагином maven-release-plugin. Разберемся, что он умеет и чем полезен.

Для начала просто добавим плагин в проект, и посмотрим на его работу с настройками по умолчанию.

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <version>3.0.0-M7</version>
        </plugin>
    </plugins>
</build>

После добавления видим новый раздел в plugins:

Плагин покрывает все операции, которые необходимо проделать перед релизом. Он может:

• Изменить версию каждого модуля отдельно или все разом.
• Прописать новый SNAPSHOT тег.
• Закоммитеть эти изменения и/или запушить их.
• Поставить релиз-тег или создать релиз ветку.
• Активировать нужные maven профили.
• Выполнить нужные maven стадии.

Все это можно выполнить либо в интерактивном режиме, либо применять значения по умолчанию, либо передавать параметрами при запуске. Последние 2 режима отлично подойдут для CI/CD.

А вот команда, которая делает большую часть работы:

mvn release:prepare

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

• Проверка наличия не зафиксированных изменений в git.
• Проверка наличия snapshot зависимостей.
• Изменение snapshot версий ваших модулей на релизные.
• Запуск maven стадий. По умолчанию это clean verify.
• Создание коммита.
• Пуш в удаленный репозиторий.
• Изменение релизной версии ваших модулей на новый snapshot

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

Одна версия для всех модулей

Если подмодули вашего приложения всегда получают ту же версию, что и родителський pom, имеет смысл указать в конфигурации плагина:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>${plugin.maven.release.ver}</version>
    <configuration>
        <autoVersionSubmodules>true</autoVersionSubmodules>
    </configuration>
</plugin>

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

Отмена push

Push в репозиторий будет выполняться по тем данным, что есть в pom в разделе scm.

<scm>
    <connection>scm:git:ssh://git@git.struchkov.dev:222/Godfather-Bots/godfather.git</connection>
    <url>https://git.struchkov.dev/Godfather-Bots/godfather</url>
    <developerConnection>scm:git:ssh://git@git.struchkov.dev:222/Godfather-Bots/godfather.git</developerConnection>
    <tag>godfather-bot-0.0.42</tag>
</scm>

Не стоить доверять пуш этому плагину. Чтобы отменить автоматический push, необходимо добавить настройку:

<pushChanges>false</pushChanges>

Формат наименования тега

По умолчанию тег получает имя в формате "artifactId"-"version-parent-pom".

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

<tagNameFormat>v.@{project.version}</tagNameFormat>

В этом примере релизный тег будет v."version-parent-pom"

Изменение стадий сборки

Как я уже упоминал выше, перед созданием первого коммита выполняется maven стадии. По умолчанию это clean verify, но можно указать свои, используя <preparationGoals>.

<preparationGoals>clean package</preparationGoals>

GPG подпись

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

<signTag>true</signTag>

Подписываем коммиты с помощью GPG

Чтобы проверить, что коммиты действительно получены из доверенного источника, в Git есть несколько способов подписать и проверить исходники, используя GPG.

struchkov.devStruchkov Mark

Резюмирую

Рассмотренный плагин maven-release-plugin значительно упрощает процедеру релиза для многомодульных проектов, что экономит время и позволяет избежать ошибок в версионировании проекта.