Работа наследования в Дженкинс рабочих мест

Question

Как вы справляетесь с отображением заданий Jenkins в процессе сборки и можете ли вы создавать каскадные конфигурации на основе наследования?

Для каждой конкретной сборки у меня будет не менее трех заданий (стандартная непрерывная интеграция)./ nightly, сканирование безопасности, покрытие) и затем некоторые последующие задания тестирования интеграции.Плагин среза конфигурации обрабатывает некоторые аспекты кросс-заданий, но каждое задание по-прежнему в значительной степени является отдельным объектом, не связанным с другими заданиями в его группе.

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

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

Как вы справляетесь со сложностьюв ваших работах по сборке в Дженкинс?Вы слышали о каких-либо серьезных проблемах с QuickBuild?

Answer 1

Я хотел бы указать вам на выпуск плагина, который моя команда разработала и только недавно опубликовала под открытым исходным кодом. Он реализует полное «Наследование между заданиями».

Здесь приведены дополнительные ссылки, которые могут вам помочь:

• Презентация: https://www.youtube.com/watch?v=wYi3JgyN7Xg
• Wiki: https://wiki.jenkins -ci.org / display / JENKINS / наследство-плагин
• Выпуски: http://repo.jenkins -ci.org / Releases / Hudson / Плагины / Проект-Наследование /

Answer 2

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

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

Вторым, что я проверил, был Ant Script для клонирования заданий и его брат Bash Script .Это действительно здорово.Идея состоит в том, чтобы заставить скрипт создать новое задание, скопировать все настройки из задания шаблона, внести необходимые изменения.Поскольку это сценарий, он очень гибкий, и с этим можно многое сделать.Единственным недостатком является то, что это не приведет к реальной иерархии, поэтому изменения в шаблонном задании не отразятся на уже клонированных заданиях, а только на заданиях, которые будут созданы в будущем.

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

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

Answer 3

Меня спросили, каким было наше окончательное решение проблемы ... После многих месяцев борьбы с нашей системой закупок мы потратили около 4000 долларов США на Quickbuild.Примерно через 2-3 месяца у нас была система шаблонных сборок, и мы были очень довольны ею.До того, как я покинул компанию, в системе было несколько групп продуктов, и мы также автоматизировали процесс выпуска.

Quickbuild был отличным продуктом.Это должно быть в классе за 40 000 $, но это оценено намного меньше.Хотя я уверен, что Дженкинс мог бы сделать это, это было бы чем-то вроде клочья, тогда как Quickbuild включил эту функциональность. Я реализовывал сложные способы поведения над продуктами раньше (например, отслеживание слияния в SVN 1.0) и сожалел об этом.Quickbuild был по разумной цене и обеспечил прочную основу для наших сборочных и тестовых систем.

В настоящее время я работаю в фирме, использующей Bamboo, и надеюсь, что его новая функциональная ветвь обеспечит большую часть возможностей Quickbuild

Answer 4

Мы используем quickbuild, и, похоже, он отлично работает для большинства вещей. Я даже смог использовать их API для написания пользовательских плагинов. Одной из областей, где не хватает быстрой сборки, является интеграция с гидролокатором. У команды гидролокатора есть плагин Jenkins, а не плагин для быстрой сборки.