I don't like any of the open source templating plugins. I think they're
rather inflexible and inelegant. I like the Cloudbees templating plugin but
it's not necessarily cheap and you need to be familiar (or become familiar)
with jelly.
We're in the same boat -- 99% of jobs share 99% of the same configuration.
We create different code branches for different release dates, and
sometimes we do parallel development, meaning we handle a *lot* of
eerily-similar jobs. Additionally, we have many, many developers and we do
not want them to directly touch the Jenkins job configuration UI. Reason
being is partly because a global support team is responsible when a
developer unknowingly hoses his/her job but still needs to cut a release by
midnight.
I solved this by externalizing the templating system. At first we wrote a
Rails app which simply accepts some input fields (job name, SCM URL, etc),
clones and populates a template config.xml, and POSTs that over to Jenkins.
But now we have too many Jenkins master instances and many active branches
of very similar code, so manually creating jobs via a web UI is too
inefficient. So I wrote a standalone application which contains a series of
template job config.xml types and a means to parse Maven POMs as input to
those templates. For instance, the job name is automatically determined via
the Maven GAV.
I've also baked-in support for arbitrary plugins; basically, anything that
can contribute extra XML passages to a main template can be added to the
tool in about five minutes. Everything supports variable interpolation,
too. So a tech lead sets up Project X, June release with the following POM
property:
<downstreamJobs>project-y-$version,project-z-$version</downstreamJobs>
When the job is created, $version resolves to "june-release" and then the
downstreamJobs section is translated into a valid XML snippet and spliced
into the template config.xml. The great thing is, in August, a
fresh-out-of-college dev can create a brand new Project X, October release
without any knowledge of the internals.
The final great thing is that this standalone application maps a SVN URL to
an appropriate Jenkins master instance (in our case, the mappings are by
business unit, which is fairly logical and standard). The app lives in an
app server with a queue in front of it, and our SVN installation contains a
post-commit hook which adds a SVN URL to that queue when the commit
contains a special message ("+makeJob", inspired by Crucible smart
commits).
Now novice developers with very little knowledge about the CI system can
create new jobs without ever entering in any technical details, and they'll
receive an email containing a link to the new job as soon as it's created.
Our goal is to allow developers to go from local commits -> artifact
repository without ever worrying about the build system in between. It was
a lot cheaper for us to engineer a good job templating system once (or
twice, really) than to eternally field support requests.
This might be overkill for you; but then again, if you're tasked with
managing thousands of jobs across a developer base with varying degrees of
Jenkins competency, it might just be up your alley. If anything, realize
that externalizing your templating system is a valid option.
PS -- I'd love to open source our templating system if anyone finds it
interesting. My day job is not keen on releasing software so I would need
some strong words of encouragement.
On Friday, February 21, 2014 10:14:47 AM UTC-5, phil swenson wrote:
>
> Hi, we have a large number of jenkins jobs and would like to automate and
> version control their configuration.
>
> From what I can tell, most people just manually config their jobs via the
> UI. Unless there are only a few very simple jobs, this leads to an
> unmanageable mess.
>
> I think the jobs should be coded in a DRY fashion, version controlled, and
> deployed via a scripted system.
>
> Here are the approaches I am aware of:
>
> 1) scripting via command line (jenkins cli)
> 2) scripting via the rest web services
> 3) chef cookbook http://community.opscode.com/cookbooks/jenkins
>
> What are most people doing?
> Any recommendations?
>
> thanks
> phil
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
