Last Updated May 11, 2014 — DevOps Expert

When discussing Release, formerly XL Release, with users, we are often asked how it relates to Jenkins or other continuous integration (CI) tools, how they can complement each other, and how best to integrate them.

At, formerly XebiaLabs, we use Release in combination with Jenkins in a number of different ways. In the second part of this blog, I’ll outline the three main integration scenarios we use. First, however, I’d like to briefly discuss the first question: how we see Jenkins (and other CI tools) and Release complementing each other.

Certainly, with pretty much any CI tool, we can chain together a number of jobs, plans, or whatever they’re called. Some tools provide additional plugins or features to also explicitly visualize this chain as a “delivery pipeline”, and can show the state of the overall pipeline by displaying the state of the individual jobs.

There are four characteristics of what we might call “real world” continuous delivery (CD) pipelines, though, that we find are addressed much more effectively by the combination of Release and a CI tool:


All stakeholders can see which features and releases are currently where, not just for one pipeline but for the set of pipelines relevant to a user in one go. CI tools can typically show you the state of one pipeline, just about, but we found it hard or impossible to quickly view a set of pipelines relevant to the current context.

With Release, every user has their own “pipeline dashboard filter”, and we can easily search on context by tagging releases, see pipelines planned to finish at a certain time, etc.



Supporting fully-automated pipelines stages (usually the initial ones) as well as time-planned, team-driven stages (usually the final ones) with some automated and some manual steps. For instance, our Release and Deploy, formerly XL Deploy, releases are accompanied by forum posts which are still manually published at present, and which need to happen on a certain date.

With only a CI tool, we found minimal, at best, support for these kind of “end game” activities, which meant that our pipelines effectively had to stop at the integration testing phase. With Release, we can still use Jenkins for what it’s good at and extend our pipeline all the way to go live – which, after all, is what you need to do in order to really start benefiting from the customer feedback loop that CD provides.


Handling dependencies in a microservice environment, or with multi-component applications, or even in the increasingly common “mobile app & backend” scenario, was something we found very hard to do satisfactorily with CI tools.

Yes, jobs/plans can often be configured to wait until another job/plan has completed, but can we ensure that we’re waiting on the correct invocation of that other pipeline? E.g. if our “release mobile app” job is waiting on the release of the backend to complete, how can we ensure it’s really the “deploy to QA” job for version 1.3.1 of the backend we’re waiting for, and not 1.3.2 or 1.3.0?

We also found it hard or impossible to effectively visualize the resulting dependency graph, or see e.g. what the potential impact on the timing of our mobile release would be if the backend testing needed to be extended or re-run, was not possible. With Release and a CI tool, we can easily track dependencies between our releases and see how delays to one component affect our overall go-live date.


One of the things we’ve learned is that you’re never “done” with improving your pipelines because they always change: new applications are added, pipelines are split as architectures are modified, release procedures change etc. etc. So for us, identifying which phases in which pipelines are the best candidates for improvement is pretty important.

Getting usable data out of a CI tool was painful: yes, we were able to extract the durations of the various jobs to come up with total throughput times for the pipeline. Identifying idle time and, especially, spotting trends across multiple runs of the same pipeline, or even multiple pipelines, ended up involving up far too much Excel magic.

Using Jenkins in combination with Release allows us to avoid most of the “homemade” reporting. We use Release’s planner to get an immediate visualization of where most of a pipeline’s time is being spent, and the automated value stream mapping to discover which phases are most in need of attention.


In the following post, I’ll discuss the three main combinations of Release and Jenkins we use: “ Release First,” “Jenkins First” and “Hybrid Pipeline”.

Are you ready to scale your enterprise?


What's New In The World of

August 4, 2023

Why Financial Services Need DevSecOps More Than Ever

With DevSecOps solutions, financial organizations can improve their security posture, meet regulatory requirements and focus on delivering innovative financial products.

Learn More
June 23, 2023

Governance and Compliance for DevOps at Scale

Implement a Software Chain of Custody in DevOps for compliance, traceability, and cost reduction. Gain visibility and automate processes with Release & Deploy.

Learn More
April 10, 2023

Continuous Delivery Implementation Done Right: Learn from National Broadband Ireland Story

Through NBI’s approach to be the best open-access operator in telecom, they have been supported by key technology partners, with automation capabilities provided by Release and Deploy underpinning integral aspects.

Learn More