1. Обзор
В предыдущей статье этой серии мы настраивали процесс развертывания с Maven для Nexus . В этой статье мы настроим процесс выпуска с помощью Maven — как в проекте, так и в задании Jenkins.
2. Хранилище в пом
Чтобы Maven мог выпускать на сервер репозитория Nexus, нам нужно определить информацию о репозитории с помощью элемента distributionManagement :
|
1
2
3
4
5
6
|
<distributionManagement> <repository> <id>nexus-releases</id> </repository></distributionManagement> |
Размещенный репозиторий релизов поставляется из коробки на Nexus, поэтому нет необходимости создавать его явно.
3. СКМ в мавенском помпе
Процесс Release будет взаимодействовать с Source Control проекта — это означает, что нам сначала нужно определить элемент <scm> в нашем pom.xml :
|
1
2
3
4
5
|
<scm></scm> |
Или, используя протокол git:
|
1
2
3
4
5
|
<scm> <connection>scm:git:git@github.com:user/project.git</connection> <url>scm:git:git@github.com:user/project.git</url> <developerConnection>scm:git:git@github.com:user/project.git</developerConnection></scm> |
4. Плагин релиза
Стандартный плагин Maven, используемый в процессе выпуска, — это maven-release-plugin — конфигурация для этого плагина минимальна:
|
01
02
03
04
05
06
07
08
09
10
|
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.4.1</version> <configuration> <tagNameFormat>v@{project.version}</tagNameFormat> <autoVersionSubmodules>true</autoVersionSubmodules> <releaseProfiles>releases</releaseProfiles> </configuration></plugin> |
Здесь важно то, что конфигурация releaseProfiles фактически заставит профиль Maven — профиль релизов — стать активным в процессе выпуска.
Именно в этом процессе модуль nexus-staging-maven-plugin используется для развертывания в хранилище Nexus -релизов Nexus:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
<profiles> <profile> <id>releases</id> <build> <plugins> <plugin> <groupId>org.sonatype.plugins</groupId> <artifactId>nexus-staging-maven-plugin</artifactId> <version>1.4.4</version> <executions> <execution> <id>default-deploy</id> <phase>deploy</phase> <goals> <goal>deploy</goal> </goals> </execution> </executions> <configuration> <serverId>nexus-releases</serverId> <skipStaging>true</skipStaging> </configuration> </plugin> </plugins> </build> </profile></profiles> |
Плагин настроен для выполнения процесса Release без механизма размещения , как и ранее , для процесса развертывания ( skipStaging = true ).
Также как и в процессе развертывания, выпуск Nexus является защищенной операцией, поэтому мы собираемся снова использовать пользовательскую форму Nexus для развертывания « из коробки».
Нам также необходимо настроить учетные данные для сервера nexus- Releases в глобальном файле settings.xml ( % USER_HOME% /. M2 / settings.xml ):
|
1
2
3
4
5
6
7
|
<servers> <server> <id>nexus-releases</id> <username>deployment</username> <password>the_pass_for_the_deployment_user</password> </server></servers> |
Это полная конфигурация
5. Процесс выпуска
Давайте разберем процесс выпуска на маленькие и сфокусированные шаги. Мы выполняем Релиз, когда текущая версия проекта является версией SNAPSHOT, скажем, 0.1-SNAPSHOT .
5.1. релиз: чистый
Очистка выпуска будет:
- удалить дескриптор выпуска ( release.properties )
- удалить любые резервные файлы POM
5.2. релиз: подготовка
Следующая часть процесса релиза — подготовка релиза ; это будет:
- выполнить некоторые проверки — не должно быть никаких незавершенных изменений, и проект должен зависеть от зависимостей SNAPSHOT
- измените версию проекта в файле pom на полный номер выпуска (удалите суффикс SNAPSHOT) — в нашем примере — 0.1
- запустить тестовый пакет проекта
- зафиксировать и подтолкнуть изменения
- создать тег из этого не-SNAPSHOT версионного кода
- увеличить версию проекта в помпе — в нашем примере — 0.2-SNAPSHOT
- зафиксировать и подтолкнуть изменения
5.3. релиз: выполнить
Последняя часть процесса Выпуска — Выполнение Выпуска ; это будет:
- Оформить заказ тега от SCM
- создать и развернуть выпущенный код
Этот второй шаг процесса основан на выводе шага Prepare — release.properties .
6. На Дженкинс
Jenkins может выполнить процесс выпуска одним из двух способов — он может использовать собственные плагины выпуска или просто запустить выполнение выпуска со стандартным заданием maven, выполнив правильные шаги выпуска.
Существующие плагины Jenkins, ориентированные на процесс выпуска:
Однако, поскольку команда Maven для выполнения выпуска достаточно проста, мы можем просто определить стандартное задание Jenkins для выполнения операции — никаких плагинов не требуется.
Итак, для нового задания Дженкинса (создайте проект maven2 / 3) — мы определим 2 параметра String: releaseVersion = 0.1 и developmentVersion = 0.2-SNAPSHOT .
В разделе конфигурации сборки мы можем просто настроить следующую команду Maven для запуска:
|
1
2
|
release:clean release:prepare release:perform -DreleaseVersion=${releaseVersion} -DdevelopmentVersion=${developmentVersion} |
При запуске параметризованного задания Jenkins будет предлагать пользователю указать значения для этих параметров — поэтому каждый раз, когда мы запускаем задание, нам нужно заполнять правильные значения для releaseVersion и developmentVersion .
Также стоит воспользоваться плагином очистки рабочего пространства и проверить опцию Удалить рабочее пространство перед началом сборки для этой сборки. Однако имейте в виду, что шаг выполнения Release должен обязательно выполняться той же командой, что и prepare шаг — это потому, что последний шаг выполнения будет использовать файл release.properties, созданный подготовкой . Это означает, что у нас не может быть подготовки к запуску задания Дженкинса и другого выполнения .
7. Заключение
В этой статье показано, как реализовать процесс выпуска проекта Maven с Jenkins или без него. Подобно развертыванию , этот процесс использует плагин nexus-staging-maven-plugin для взаимодействия с Nexus и фокусируется на git-проекте.