Continuous Delivery - Part 1: Our Jenkins Build Pipeline setup


July 7, 2011

As part of our journey towards implementing Continous Delivery, I’ve added the  Build pipeline for our continous integration server Jenkins. There are quite a few resources available on the net on how to add the plugin and configure it. This blog is not about how to configure the plugin, but more on how I’ve configured it for one of our projects and issues I faced while doing the same.

The pipeline we have now is very simple. They are:

The problems we had with our earlier approach, and how the current approach solved those problems:

What we had in the past was, simple scripts with the above items. We had a job for running the tests. If the build was successful, we would run  capistrano scripts to deploy to staging and once the customer gave the thumbs up, we’d push it to production. There are a series of steps that we had to do for each deployment. For eg: for staging deployment:

And almost similar steps needed to be followed for production deployment also. The usual problems that we used to face are:

With the current approach, the advantages are:

One of the major problems I had faced in the earlier “manual” system - was the inability to pass parameters between builds. For example, once the app would be moved to staging, a tag is created and when its ready to be pushed to production, we’d have to merge that particular tag to production and then push it.

To achieve the above I used the “parameterized build” option. In Jenkins, the parameters get converted to Environment Variables and got passed to the downstream job. When you fire the build, it prompts for the value of the parameter. Once entered this would be available as an Environment variable for this job and all its downstream jobs.

For eg: in the pipeline, the downstream project is “Stage deploy”, and it will know the value for TAG and uses that value to create a tag in Git after successful deployment.

When it is ready for production deployment it merges with the same tag and deploys to production. In the latest version of the plugin, moving to the next step is not triggered automatically and you can retry the failed ones.

Note: Capturing the parameter will happen only for the first job. So, if the parameterized job is not the first one in the pipeline, the capture of the parameter will not happen.

So we’ve reached the “one click deployment stage” with this. But we’ve still got the following pending tasks - based on what’s mention in the book Continuous Delivery: