The views presented here are my own and not of my employer

I was reading through the conversation at DevOps tool-chain group. The problem posted was difficulty of using Jenkins as a delivery pipeline. Specially when it comes to complex workflows for example diamond dependencies, fan out & fan in etc. My thoughts after reading post were (Which you will see being different later):

• Though you can use Jenkins to build continuous deliver pipelines, there are better suited and specialized “deployment automation” tools for the job:
  • CA Release Automation Center (Formerly Nolio from Noliosoft) : The tool I was trained and been playing since
  • LiveRebel from Zeroturnaround: I had test driven this a few months before – loved some awesome features like rolling deployments etc.
  • DeployIT from XebiaLabs: Heard recently and started exploring, got a demo at DevOpsDays. Could not yet test drive (Dosen’t offer a trial version on website as of writing this article)
• I was intrigued and started exploring the tools mentioned in the post. Should one use a CI tool like Jenkins to build delivery pipelines? Or use specialized tools mentioned earlier for continuous delivery? Or choose one good tool and use for both purposes? Are there tools which can do both well and how to choose one – these are questions we are trying to answer in this post.

Continuous Integration

Continuous integration primarily focuses on building code, running tests and ensuring the code is in “clean” state. Since latest state of software is primary purpose – older builds and changes are lesser important as you move forward.

Continuous delivery/deployment

Continuous delivery focuses on deploying a set of changes to one/more environments. The process is typically a set of steps with decision points, parallel flows and roll forward and roll back steps. Basically continuous delivery is comparatively complex workflow with some specialized actions like rolling deployments, talking to servers etc.

In contrast to a continuous integration process, in continuous delivery –

• Not every build will be deployed – more often than not a deployment candidate might be sum of last few builds. (Ex. Build 450-458 forming deploy version 1.7.4 of software).
• Changes done for a deployment candidate are sum of all changes done for all builds since previous deployment. Moreover a continuous delivery process has to have knowledge of which build was deployed when and where.
• The level & granularity of access control needed for a CI process is vastly different than for a CD process. You might want most people to be able to kick off a build but not deploy the artifact to certain environments.

The gap!

As we can see CI and CD process use vastly varied semantics, they aim to achieve different objectives. They handle different units of work and the complexity of process are different too! So should you use one tool to do two things? Let’s try it out. We will test drive Go (From ThoughtWorks), TeamCity (from JetBrains), Bamboo (From Atlassian),Jenkins (OpenSource) and and see how do they fit in.

Parameters for using a CI tool for CD

1) Support for CI+CD Semantics: Ability to suppport dual semantics for example information from multiple builds into a release candidate

2) Workflow designer: Visual workflow – to build workflow which is easy to see and modify over time

3) Features: Standard actions available for various CD tasks  – like deploy to tomcat, connect to server XYZ etc.

4) Extensible: Ability to write custom actions/plugins for doing adhoc jobs – because not all actions provided in tool might fit your needs.

5) Miscellaneous factors: Can you build rolling deployments? Is it agentless or needs agents on target machines? Does tool support horizontal scalability for handling huge volumes (Which is tied to agent based model to some extent) etc.

So let’s test drive one by one!

Go- ThoughtWorks

Using CI for continuous delivery Part 1

Go almost felt like a tool which is malleable and would fit well in your organizations’s existing knowledge (Scripts, Tools etc.). It’s minimalist interface coupled with a very good visual workflow builder gives you a perfect candidate which you can use to build continuous delivery pipelines.

TeamCity- JetBrains

Using CI for continuous delivery Part 2

TeamCity – which is an excellent CI tool had to be fit in to do continuous delivery tasks. It can be a good fit for doing simpler continuous delivery pipelines if you have a wide variety of technologies- handling which is a unique strength of TeamCity.

Bamboo – Atlassian

Using CI for continuous delivery Part 3

Bamboo came out as one of best candidates for doing both Continuous Integration and continuous delivery at the same time. Product understands the two paradigms separately and handles them that way.

Jenkins – Open Source

Using CI for continuous delivery Part 4

Though it is possible to build continuous delivery pipelines in Jenkins – it felt a little unnatural. We did not explore all possibilities with many plugins available, but at the surface it looked feasible – but not natural.

Conclusion

We used continuous integration tools to also do continuous delivery – and surprisingly some tools like Go and Bamboo did a real good job of it. Does this means using specialized tools for continuous delivery is not needed? Definitely no! We used a rather simplistic scenario and did not deploy at a scale which is common in many companies today. So that conclusion would be half baked.

Nevertheless I believe that companies which already have these tools can start implementing continuous delivery pipelines – they may not be perfect but you will understand what works well. Some of your pipelines might as well be better residents within CI tools. You will also gain valuable insights into your delivery pipelines and will aid in better decision while buying the continuous delivery tool! Secondly if the budgets for CD tool is not very high – it might make sense to get started with these tools and eventually make decisions on buying CD tools.

Would love to understand the CI and CD scenario of your team!