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".

 

XL Release First

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

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 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
Jun 10, 2021

Desilo DevOps: The power of bringing all your tools and data into one view

DevOps
When discussing value stream management (VSM), our resources talk a lo ...
Read More
Jun 07, 2021

"How do I get started?" Key steps to improving your end-to-end DevOps process

DevOps
There is an extraordinary variety of DevOps solutions available on the ...
Read More
May 24, 2021

Integrate your DevOps toolchain, simplify your life

DevOps
Organizations can view the entirety of the tools and platforms they us ...
Read More
May 17, 2021

Why Companies in Competitive Industries Adjusted Better During COVID-19

DevOps
As we continue to assess the dramatic effects of the global COVID-19 p ...
Read More
Contact Us