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

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.