What about versioning of Jenkins/Hudson jobs?

Problem

I am sure (hopefully) everyone is using a Source Code Management System (SCM) for their sourcecode. But what about versioning of your jobs within a continuous integration system like Jenkins (or Hudson)? Have you ever had the situation, that a colleague made a change to a job 5 minutes before he went out for holiday?

At the next morning you step into your office and the build bears are RED (see picture on left side). You are wondering about that and dig into the last changes within the SCM to find the solution for the broken build. After a few minutes or hours you realize that the changes to the SCM are not the root cause for the problem. What now? Possibly a colleague has changed the job on the continuous integration system? But if so where is the change?

Possible Solution?

I observed such a problem in my current project and decided to write a plugin that helps to prevent such a situation. But then I noticed that there is a plugin that is able to handle such situations. This plugin is called “SCM Sync configuration Plugin”. You can find it here.

My problem is solved!

Shorty after discovering that plugin I installed and tested it on a local test instance. It was working very well so I also installed it on production and right now every change that is made to the global configuration or to a job is committed into my SCM. So I am able to handle a situation like described above. All my Jenkins configuration changes are stored as commits in my SCM. I really love it. 🙂

How to restore?

The change sets can not be viewed/compared directly in Jenkins. You have to do that in your SCM. In case of a job restore you have to copy the config.xml from your SCM to the Jenkins server and reload the Jenkins configuration.

By the way – I use that plugin with an git SCM repository. The plugin also supports Subversion and maybe a few more in the future.

-Dirk