В настоящее время я улучшаю процесс выпуска наших проектов на Jenkins (1.430).
Текущие задания выпуска
Сегодня для одного конкретного проекта у нас есть одна работа, посвященная процессу выпуска. Полная процедура следующая:
- Разработчик, который отвечает за выпуск, вручную изменяет версию всех файлов pom.xml(фактически используя
mvn versions:set -DnewVersion=2.0), чтобы избавиться от-SNAPSHOT. - Затем он создает тег в SVN (http://my-svn-repo/project/tags/V_2_0, например).
- Как только этот тег был создан, он регистрируется на нашем сервере Jenkins и запускает сборку Release.
- Эта сборка спросит его, какой тег он хочет использовать для сборки. Задача сконфигурирована как сборка с параметрами, с тегами Subversion в списке параметров.
- Затем Jenkins построит артефакты из этого тега и развернет их в нашем экземпляре Nexus.
- Как только это будет сделано, разработчик установит версии pom.xml в новую версию разработки (т.е.
2.1-SNAPSHOT).
Преимущество этого метода в том, что у меня есть только работа Jenkins, так как сборка будет полагаться только на тег.
Однако эта процедура включает слишком много человеческих interventiosns (изменения pom.xml, коммитов, тегов и т.д.).
Новые задания для отпуска
Теперь я использую плагин выпуска Maven. Я создал задание, которое запрашивает три информации для пользователя, который запускает сборку:
- версия выпуска (параметр
releaseVersionплагина выпуска); - версия разработки после выпуска (параметр
developmentVersionплагина выпуска); - имя тега (параметр
tagплагина выпуска).
Это задание отлично работает, за исключением одной точки: задание основано на соединительной линии или на ветке в SVN. Это означает, что если у меня есть 2 ветки (в дополнение к багажнику), мне нужно будет создать 3 задания на выпуск: по одной ветки.
Одна идея сохранить лучшее из двух миров (т.е. использовать mvn-релиз, но сохранить 1 выпускное задание), чтобы добавить параметр сборки, который будет запрашивать у пользователя путь к соединительной линии/ветке.
Поэтому вместо настройки http://my-svn-repo/project/trunk (или http://my-svn-repo/project/branches/BRANCH_V1) в конфигурации задания я установлю http://my-svn-repo/project/$FROM_BRANCH и попрошу пользователя ввести параметр FROM_BRANCH.
Проблема с этим решением заключается в том, что пользователю придется вводить либо trunk, либо branches/BRANCH_Vx, что может привести к ошибкам.
В идеале, мне бы хотелось иметь параметр построения, который позволяет мне выбирать ветку (включая тубус), поскольку существуют теги Subversion для списка параметров для выбора тегов...
Итак, мой вопрос: есть ли лучший способ настроить работу one Дженкинса, которая может работать на всех ветвях?
Спасибо.
Изменить: я нашел Validating String плагин Jenkins, который может быть интересен, чтобы гарантировать, что значение, определенное пользователем, соответствует некоторому регулярному выражению. Это полезно в моем случае...
