Профили Дженкинса и Мейвена

Изменить: Jenkins 2 выпущен и имеет встроенную поддержку конвейеров. .

Несколько указателей для ваших требований:

1. "созданы целые проекты, если есть какие-либо изменения в SCM"

   • Хотя Poll SCM обычно требует меньше работы, правильный способ сделать это — использовать перехватчики SVN.

     Решение работает следующим образом:

     • First you enable the Trigger builds remotely feature and enter a random token in Authentication Token.
     • Это позволяет запускать сборки удаленно с помощью Jenkins REST API (http[s]://JENKINS_URL/job/BUILD_NAME/build?token=TOKEN)

     • Затем вы создаете хук SVN (скрипт, который запускается всякий раз, когда вы фиксируете), который запускает сборку, отправляя запрос на этот URL-адрес (используя curl, wget, python,...).

       Существует множество руководств по созданию хуков SVN, вот первый результат на "SVN Hooks" от Google.

2. "сохранять зависимость между проектами"

   • I would create a different Jenkins Job for each project separately, then make sure builds are executed in the required order.

   • Я думаю, что лучший способ упорядочить ваши сборки (зависимости) — это создать Build Pipeline с помощью Подключаемый модуль конвейера (ранее известный как подключаемый модуль рабочего процесса).

     Здесь есть что объяснять, так что лучше читайте сами. Вы можете начать здесь.

     Существуют и другие (более простые) решения, такие как плагин Build Flow. или плагин параметризованного триггера, который может помочь создать зависимости между сборками, но Я думаю, что Pipeline является самой новой и считается лучшей практикой (это определенно самое продвинутое решение).

     Тем не менее, сказав это, если вы чувствуете, что Pipeline - это излишество для вас, воспользуйтесь альтернативами.

   • Я бы рекомендовал убедиться, что каждая сборка выполняет mvn install в одном и том же локальном репозитории, а также развертывает артефакт в Artifactory (надеюсь, он у вас есть).

3. Автоматизация параметризованных сборок: "сборка с профилем tomcat и профилем websphere"

   • To do that you'll need to create parameterized builds.
   • Это довольно легко сделать, вы просто проверяете This build is parameterized в конфигурации сборки и добавляете параметр строки/выбора MVN_PROFILE.
   • После этого вы можете запускать каждую сборку несколько раз с разными параметрами, используя любой из плагинов, упомянутых в предыдущем пункте.

Дополнительный совет:

Разбираясь с этим, рассмотрите возможность использования плагина истории конфигурации заданий. может помочь просмотреть и отменить изменения, внесенные в конфигурацию.

Удачи, Надеюсь это поможет :)

Мои знания maven ограничены, однако, поскольку вы еще не получили ответа, я попытаюсь дать несколько общих советов.

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

Однако сначала вам нужно что-то, что просто работает, а затем вы можете это усовершенствовать.

Быстрый результат вы получите со следующим

Все в одной работе

• Настройте репозиторий Subversion (возможно несколько), чтобы он был проверен в вашей рабочей области.
• Включить триггер Опрос SCM
• Создавайте свои модули/проекты с помощью шагов сборки Execute shell. (Неудачные сборки можно передать результату задания, используя Exit 1 на шаге Execute shell сборки.)

Однако имейте в виду, что это предотвратит расширенные функции для каждого проекта/модуля, такие как почтовые уведомления виноватому разработчику. Или тенденции показателей, таких как предупреждения или статический анализ кода.

Следующее решение легче расширить в этом направлении.

Работа-оболочка вокруг ваших различных заданий сборки

• Используйте этап сборки Запуск/вызов сборок для других проектов, чтобы построить A, заархивировать необходимые артефакты.
• Используйте этап сборки Запуск/вызов сборок для других проектов с некоторым параметром tomcatдля сборки B tomcat версии используйте Copy Artifact Plugin для копирования jar из A
• ...
• Используйте этап сборки Запуск/вызов сборок для других проектов с некоторым параметром tomcatдля сборки E tomcat версии. Используйте плагин Copy Artifact для копирования всех необходимых артефактов, вы можете указать там параметр, если вам нужен артефакт, например, версии B tomcat

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

Возможное решение: разделите рабочее пространство между заданием-оболочкой и заданиями сборки, чтобы дублирующие проверки в заданиях сборки находили файлы, уже находящиеся в нужной версии. Однако тогда вам *нужно+ убедиться, что последующие задания выполняются на той же машине (для этого есть плагины)

Или еще более элегантно: используйте перехватчик после фиксации (см. здесь, раздел Post-comit hook) на вашем svn, чтобы уведомлять jenkins об изменениях.

Изменить. В будущем стоит изучить плагин Pipeline. и его документацию для более сложных сборок, это движок для будущей версии jenkins 2.0. , см. здесь.

Я бы создал 5 разных рабочих мест для ABCDE.

Как вы упомянули, A и C будут автономными заданиями, поэтому я просто выполню mvn clean install/pkg/verify в зависимости от ваших потребностей.

Для B я бы сначала построил A, а затем вызвал другую цель maven в сборке для сборки B.

Для D я бы сначала построил C, а затем построил D

Наконец, для E я бы использовал вызов mvn-целей верхнего уровня 5 раз A, B, C, D и, наконец, E

Я бы рассмотрел немного другой подход, чтобы полностью разделить проекты. Если вы можете создать свой внутренний артефакт, я бы рассмотрел в сборке maven каждую из зависимостей как стороннюю библиотеку точно так же, как это делается с любыми другими внешними библиотеками, которые вы используете. Таким образом, каждый такой проект может быть создан отдельно и сохранен в артефакте, и когда будет построен зависимый проект, он просто возьмет правильную версию, как указано в файле pom. Таким образом, у вас будет разный процесс сборки для каждого из проектов, и будут построены только соответствующие проекты (соответствующие = измененные).