Skip to main content
Three Ways of Using XL Release & Jenkins for Continuous Delivery (part 2)

This post is from the XebiaLabs blog and has not been updated since the original publish date.

Last Updated May 17, 2014 — DevOps Expert

Three Ways of Using XL Release & Jenkins for Continuous Delivery (part 2)

DevOps

In the previous post, I outlined how combining XL Release, and Jenkins to orchestrate our delivery pipelines allows us to address four important Continuous Delivery challenges that we couldn't satisfactorily handle with a Continuous Integration tool alone: visibility, flexibility, scalability and improvement. Here, I'd like to describe the three main ways we combine XL Release and Jenkins in our delivery automation: "XL Release First", "Jenkins First" and "Hybrid Pipeline".

Digital.ai Release first approach

XL Release FirstDigital.ai Release default configuration

This is our default configuration for releases or pipeline runs that are triggered by process activities rather than code events (e.g. "when requested by the business owner), or that happen regularly but not to a precise schedule (e.g. "after the sprint demo, if approved"). In this setup, a release/pipeline run is started via the XL Release UI, or automatically from e.g. an ALM tool such as JIRA, Rally, RTC or VersionOne via the HTTP API. The first phase of the pipeline usually invokes Jenkins, to build the release artifact(s), verify that a previous build was successful, or was promoted etc. We often invoke Jenkins again from subsequent phases, e.g. to retrieve artifact fingerprints or verify unit test or static code analysis results. We'll often also make use of Jenkins' many integrations with other tools to trigger e.g. mobile tests and retrieve their results. An important thing to note about this setup is that the Jenkins jobs in question trigger other Jenkins jobs only when that is necessary to carry out the particular task at hand, e.g. if two or three jobs are involved in producing the build artifacts. The orchestration from one pipeline phase to the next takes place in XL Release. Triggers: process-related and/or "semi-regular" Interaction: XL Release calls Jenkins once or multiple times throughout the release/pipeline run. Jenkins jobs generally do not call downstream jobs.

 

 

Jenkins first approachJenkins FirstDigital.ai Release plugin screenshot

This is our default setup for releases or pipeline runs that are triggered by code events or on a regular schedule, e.g. when a commit is merged to the main branch, or every night etc. Jenkins providers plenty of options and integrations to listen for such code-level events, and we then trigger a new release/pipeline run in XL Release using the Jenkins XL Release plugin.  In other respects, this configuration is similar to "XL Release First": we will often call Jenkins again multiple times from different phases of the release/pipeline, but orchestrate the phases of the pipeline from XL Release. Triggers: code-related and/or regular Interaction: Jenkins initially creates and starts the release/pipeline run via the Jenkins XL Release plugin. XL Release then often calls Jenkins once or multiple times throughout the release/pipeline run. Jenkins jobs generally do not call downstream jobs.

 

Hybrid approachHybrid pipelineHybrid Pipeline

This is standard approach we take for onboarding existing applications. These typically already have more or less extensive Jenkins pipelines that automate the build and testing activities up until around QA/UAT. Here, the initial focus is on taking the output of the existing pipeline and "going the last mile" to Production. If the application or service consists of multiple components, we often see multiple Jenkins pipelines "coming together" for this last phase. In the "Hybrid Pipeline" scenario, the release/pipeline run in XL Release is either triggered at the end of the Jenkins pipeline via the Jenkins XL Release plugin, manually or from a process tool such as an ALM or Change Management system - it really depends on the application. Most of the tasks in the "last mile" to Production - at least initially - tend to be manual or process-oriented, such as creating change tickets, verifying approvals etc. We don't often see Jenkins triggered from XL Release in this setup. However, as we progressively automate the release to Production, we sometimes end up retrieving information, such as artifact fingerprints or test results from the Jenkins part of the pipeline, for verification, and to ensure we have all the information needed for a release audit in one place.

Triggers:

  • Jenkins section: code-related
  • XL Release section: from Jenkins, manual or from process tool

Interaction: Jenkins runs the initial part of the pipeline, typically until QA/UAT and sometimes automatically triggers XL Release on completion. As the last mile to Production in XL Release is progressively automated, XL Release often ends up calling Jenkins to retrieve information (fingerprints, test results, commit IDs etc.) about the initial pipeline stage.

 

More from the Blog

View more
Mar 04, 2021

Getting key stakeholder buy-in for changes perceived as risky

DevOps
Organizational leaders must recognize that change is vital for the sur ...
Read More
Mar 01, 2021

Discover the change management practices that are ripe for optimization

DevOps
Change has become the most important part of modern digital product cr ...
Read More
Feb 22, 2021

Reckoning DevOps’ role in the enterprise value stream

DevOps
If you’re a software or digital solutions company, you may use DevOps ...
Read More
Feb 10, 2021

Customer spotlight: Schneider avoiding bumps in the road with DevOps adoption

DevOps
Everyone wants to deliver software faster and more reliably. Companies ...
Read More
Contact Us