Шаблон рабочих процессов в Jenkins

Question

Каждый труба jenkins делает почти то же самое - по крайней мере в небольшой команде с несколькими проектами.

Build (из того же Исходник- репо) -> выполнить тесты -> публиковать артефакты (в тот же артефакт репо)

Мы создаем много новых проектов, и все они имеют очень похожий жизненный цикл. Можно ли создать конвейер шаблонов, из которого я могу создать конкретные pipleines и внести необходимые изменения в задания?

Answer 1

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

часть 1) заключается в том, чтобы определить, какие плагины для оркестровки лучше всего подходят для дженкинсов. Плагиных и подходы, которые работали хорошо для меня были:

а) Используйте http://ci.openstack.org/jenkins-job-builder/ It абстрактных Определений рабочих мест и потоки с использованием более высоким уровнем библиотеки. Это позволяет вам определять задания в YAML, что довольно просто и поддерживает большинство распространенных случаев использования (заданий, шаблонов, потоков). Эти файлы yaml затем могут быть использованы утилитой python cli для jenkins-jobs-builder с помощью инструмента для оркестровки, такого как доступный, кукольный, повар. Вы можете использовать YAML анкеры для замены блоков, которые являются общими для нескольких рабочих мест, или когда-либо шаблона их из шаблона двигателя (ERB, jinja2)

б) С помощью рабочего процесса-плагин, https://github.com/jenkinsci/workflow-plugin Плагин документооборота позволяет иметь единый рабочий процесс в groovy, а не набор заданий, которые объединяются вместе.

«Например, чтобы проверить и построить несколько хранилищ параллельно, каждый на своем ведомом:

parallel repos.collectEntries {repo -> [/* thread label */repo, { 
    node { 
     dir('sources') { // switch to subdir 
      git url: "https://github.com/user/${repo}" 
      sh 'make all -Dtarget=../build' 
     } 
    } 
}]} 

»

Если вы строите эти определения рабочего процесса из шаблона двигателя (ERB, jinja2), и интегрировать их с инструментом управления конфигурацией (опять же, шеф-поваром, марионеткой). Становится намного легче сделать небольшие и большие изменения, которые влияют на одну или все задания. Например, вы можете использовать шаблон, который некоторые коробки jenkins собирают, публикуют и развертывают артефакты в среде разработки, в то время как другие просто развертывают артефакты в среде QA. Все это может быть достигнуто из того же шаблона, используя операторы if/then и макросы в jinja2/erb.

Ex (абстракция):

if ($environment == dev=) then compile, publish, deploy($environment) 
elif ($environment== qa) then deploy($environment) 

часть2), чтобы убедиться, конфигурация всех Дженкинс для всех рабочих мест и потоков хранится в системе управления версиями, и убедитесь, что изменение определения работы в источнике управление будет автоматически распространено на сервер (ы) jenkins (опять же, марионетка, шеф-повар). Или даже иметь работу jenkins, которая контролирует собственное репо определений рабочих мест и автоматически обновляет себя

Когда вы достигаете # 1 и # 2, вы должны быть в положении, где вы можете с некоторой уверенностью разрешить всем членам вашей команды сделать изменения их рабочих мест/проектов, предоставление вам информации о том, кто изменил то, что и когда, и иметь возможность легко откатываться от контроля изменений, когда все идет не так.

его в значительной степени о том, чтобы заставить jenkins развернуть код из серии шаблонных заданий, которые сами были определены в коде.

Answer 2

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

1. j2 шаблонов, созданные для различных рабочих мест
2. цикла переходит определения проекта и обновление работы и представление в Дженкинс

3. по умолчанию общего определения используются, и очень минимальное описание требуется:

   default_project: 
       jobs: 
       Build: 
        template: build.xml.j2 
       Release: ... 
   
   projects: 
       DefaultProject1: 
       properties: 
        repository: git://../.. 
       CustomProject2: 
       properties: 
        a: b 
        c: d 
       jobs: 
        Custom-Build: 
        template: custom.j2