Управление релизами - Maven, Bamboo и JIRA - PullRequest
4 голосов
/ 06 сентября 2011

Я бы хотел найти лучший способ управления выпусками с использованием Maven 2, Bamboo 3.1 и JIRA 4.3.Я перепробовал много вещей, но продолжаю заходить в тупик из-за ошибок или отсутствия функциональности.

Моя конечная цель - получить версии из JIRA, заставить Bamboo взять эти версии и собрать из них артефакты с помощью Maven, а затем развернутьэти артефакты в хранилище (Nexus в нашем случае).

Вот подходы, которые я попробовал:

1) Используйте заполнитель во всех poms для версий проекта:

Parent pom

<project ...>
  <groupId>group</groupId>
  <artifactId>parent</artifactId>
  <version>${ci.version}</version>
  ...
  <modules>...</modules>
</project>

Child pom

<project ...>
  <parent>
    <groupId>group</groupId>
    <artifactId>parent</artifactId>
    <version>${ci.version}</version>
  </parent>
  <artifactId>child</artifactId>
  ...
</project>

Эта сборка выполняется, если вы запускаете сборку из корневого pom проекта и указываете -Dci.version=<my-version> в командной строке.Объедините это с Bamboo Release Management Plugin , и я могу создавать и развертывать версии своих модулей и выпускать их по мере необходимости.

Проблема этого подхода заключается в том, что Maven не заменяет переменные-заполнители вpoms при развертывании или установке, что означает, что у poms в хранилище есть маркер ${ci.version}, когда я действительно хотел бы, чтобы они имели конкретную версию.Из-за заполнителя это означает, что никто не может использовать развернутые мной модули.См. MNG-2971 .

2) Используйте конкретные версии SNAPSHOT в pom и настройте бамбук для выполнения Maven Release Plugin с помощью Bamboo Release Management Plugin.

К сожалению, плагину Maven Release требуется версия для увеличения, а бамбуковый плагин позволяет вам получить имя текущей версии для сборки, но не следующую.Без этой информации использование Maven Release Plugin приведет к увеличению версии до чего-то, что не управляется JIRA.Чтобы эта опция работала, мне либо понадобится следующая доступная мне версия, либо я смогу запустить план после того, как плагин Bamboo Release Management выполнит свою задачу (это второе исправление также добавит дополнительный беспорядок в журналы фиксации, как выполучите один коммит для автоматического приращения и один для правильного приращения).

2.b) То же, что 2), но вам нужно указать следующую версию в Bamboo перед сборкой любого релиза через интерфейс конфигурации плана, установивзначение вручную до следующей версии JIRA, над которой должен работать план.Это решает проблему с 2), но добавляет дополнительные ручные шаги.

3) Делайте вещи вручную, возможно, используя плагин Maven Release.Полностью игнорируйте все функциональные возможности выпуска в Bamboo и вручную управляйте выпуском в командной строке, вызывая цель Плагин релиза Maven для изменения версии по мере необходимости.Версии JIRA также должны быть выпущены вручную, когда это произойдет.Нам также необходимо настроить бамбуковую сборку для запуска и тестирования тега, создаваемого плагином релиза для не-SNAPSHOT-версии.

В этом параметре задействовано столько процессов, что что-то может пойти не так.

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

Спасибо

1 Ответ

0 голосов
/ 16 декабря 2011

matt,

Вы должны указать в своей цели -Dci.version = {bamboo.custom.brmp.name} Я наткнулся на ваш вопрос, когда искал точно такую ​​же информацию, но потомJIRA 4.4 и Bamboo 3.3, где плагин управления релизами был заменен / обновлен плагином JIRA Bamboo ...

Надеюсь, это поможет,

Фрэнсис

...