Template workflows in Jenkins

There are a couple of approaches that I use that work well for me and my team.

part 1) is to identify which orchestration plugins suits you best in jenkins.Plugins and approaches that worked well for me were:

a) Use http://ci.openstack.org/jenkins-job-builder/It abstract the jobs definitions and flows using a higher level library. It allows you to define jobs in YAML which is fairly simple and it supports most of the common usage cases (jobs, templates, flows). These yaml files can then be consumed by the jenkins-jobs-builder python cli tool through an orchestration tool such as ansible, puppet,chef.You can use YAML anchors to replace blocks that are common to multiple jobs, or ever template them from a template engine (erb,jinja2)

b) Use the workflow-plugin, https://github.com/jenkinsci/workflow-pluginThe workflow plugin allows you to have a single workflow in groovy, instead of a set of jobs that chain together.

"For example, to check out and build several repositories in parallel, each on its own slave:

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'        }    }}]}

"

If you build these workflow definitions from a template engine (ERB, jinja2), and integrate them with a configuration management tool (again ansible,chef,puppet).It becomes a lot easier to make small and larger changes that affect one or all the jobs.For example, you can template that some jenkins boxes compile, publish and deploy the artifacts into a development environment, while others simply deploy the artifacts into a QA environment.This can all be achieved from the same template, using if/then statements and macros in jinja2/erb.

Ex (an abstraction):

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

part2) is to make sure all the jenkins configuration for all the jobs and flows is kept in source control, and make sure a change of a job definition in source control will be automatically propagated to the jenkins server(s) (again ansible, puppet, chef).Or even have a jenkins jobs that monitors its own repo of jobs definitions and automatically updates itself

When you achieve #1 and #2 you should be at a position where you can with some confidence allow all your team members to make changes to their jobs/projects, giving you information of who changed what and when, and be able to rollback changes easily from change control when things go wrong.

its pretty much about getting jenkins to deploy code from a series of templated jobs that were themselves defined in code.

Another approach we've been following is managing jobs via Ansible templates. We started way before jenkins_job module became available, and are using url module to talk to jenkins, but overall approach will be the same:

1. j2 templates created for different jobs
2. loop goes over project definitions, and updates jobs and views in jenkins

3. by default common definition is used, and very minimal description is required:

   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