Three Ways of Using XL Release & Jenkins for Continuous Delivery

| May 12, 2014 | 1 Comment

jenkins-and-xlreleaseWhen discussing XL Release with users, we are often asked how it relates to Jenkins or other Continuous Integration tools, how they can complement each other, and how best to integrate them.

At XebiaLabs, we use XL 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 XL 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 pipelines, though, that we find are addressed much more effectively by the combination of XL Release and a CI tool:

Visibility

Showing all stakeholders 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 XL Release, every user has their own “pipeline dashboard filterrelease-overview-filter, and we can easily search on context by tagging releases, see pipelines planned to finish at a certain time, etc.

Flexibility

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 XL Release and XL Deploy releases are accompanied by forum posts which are still manually published at present, and which need to happen on a certain date.

xlr-teams-toolsWith 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 XL 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.

Scalability

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 how to 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 to 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?

xlr-calendarWe 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 XL 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.

Improvement

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 XL Release allows us to avoid most of the “homemade” reporting. We use XL Release’s plannerplanner-default-sequence 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 XL Release and Jenkins we use: “XL Release First”, “Jenkins First” and “Hybrid Pipeline”.


About the Author ()

Andrew Phillips is the VP of DevOps Strategy at XebiaLabs. He is a DevOps thought-leader, speaker and developer.