Jenkins and Promoted Builds

I have been revisiting at the automated build system that we use at work. It is a automated representation of the old manual builds system that existed 18-months ago.

For many reasons I have been unhappy with the situation, which represents a compromise on the purity of the system against what we could do in the time.

At the same time we are moving to Subversion, and I want to be able to remove svn  at a later date and replace it with another if required. The use of a different SCM is not the difficulty here!

The situation is that we have a live branch of code, and a development branch of code. Developments go into the 'dev' branch, are tested and QAed and the promoted to the live code. Previously we have used a 'holding' level were code can be checked in at anytime. 

We are going to used Promoted Builds in Jenkins to make this happen. Referring to the blog entry from CloudBees - Another Look at the Jenkins Promoted Builds Plugin, I have setup the standard svn structures for 'live' and 'dev'.

There are eight Jenkins jobs (there could be less, but I like pipelining), breaking down the pipeline of builds, 1 pipeline is the standard CI builds for the 'dev' branch. This consists of Build -> Test -> Deploy pipeline.

CI pipeline

Developers will commit changes to the code repository and that triggers the initial build job - development2. Once this has been successful, it will trigger the development2-tests job, which runs tests, gathers code-coverage statistics. When these pass, it then triggers the development2-deploy task, which copies the builds to the server holding the developer test environments.

A second pipeline (promoting and deploying to QA) is triggered by a manual promotion from the development2 build. This allows the code to be recompiled in release conditions, and deployed to the QA staging area.

The final pipeline (promoting and rebuilding the live system) is triggered by a second manual promotion from the development2 build. This allows the code to be merged into the live branch, and then rebuilt and deployed. The 'live' is not the code that gets delivered to the client, the QAed code goes out the door. It is just there to represent the fully tested code.