Continuous Delivery with Jenkins -- Part 2

This is Part 2 of a new series of blog posts about Continuous Delivery with Jenkins and the new Pipeline feature. Follow along in the coming weeks to learn more!

Jenkins: The Obvious Choice for Continuous Delivery

Most organizations already have a continuous integration (CI) practice in-house before they start walking up the ramp toward continuous delivery. Technical management frequently finds that Jenkins is the de facto tool of choice (Image 1) for their development teams and that their developers love Jenkins.

Image 1: Jenkins is used by 70% of developers responding to a recent survey. (Survey conducted by ZeroTurnaroud, Java Tools and Technologies Landscape for 2014 , May 21, 2014.)

As experience with Jenkins grows, teams extend Jenkins beyond CI, with release and deployment the next obvious automation points in the software delivery lifecycle. Based on a survey conducted by CloudBees at the 2012 Jenkins User Conference, almost 50% of respondents use Jenkins to release and deploy software (Image 2).

Image 2: Jenkins in the organization. (Jenkins Community Survey , published January 8, 2013)

There are two key reasons for such widespread adoption of Jenkins. The first reason is that Jenkins is open source and has an extremely active, vibrant community supporting it. The second reason is Jenkins’ extensible DNA. This DNA is also the root cause of the vibrant Jenkins community.

Users can extend Jenkins by developing plugins and Jenkins provides numerous extension1 points for adding custom functionality. As a result, there is a plugin2 available for virtually every tool on the market. Thus, Jenkins gives the flexibility to connect with existing tools used within any stage of the lifecycle to support continuous delivery (Image 3). If in-house tools are being used, developers can easily write a plugin for them, too. This means that the potential risk in implementing continuous delivery is lower with Jenkins compared to other tools, since organizations do not need to rip out their existing toolsets.

Building upon the vibrant community platform, Jenkins products from CloudBees further reduce the risk as organizations can get formal support for Jenkins and other value-add, enterprise-level features.

Image 3: Jenkins plugins exist for a wide variety of existing tools used within any stage of the software delivery lifecycle.

Prerequisites for Continuous Delivery

There are common requirements teams have for any CI tool such as Jenkins in order to deliver software continuously. Here are the salient ones:

• Define complex pipelines: Delivery pipelines are typically more complex than canonical examples (linear process: Dev->Test->Deploy, with a couple of operations at each stage). Build managers want constructs that help parallelize parts of the flow, run loops, perform retries and so forth. Stated differently, build managers want programming constructs to define pipelines.

• Survive failures in the underlying infrastructure: A commit, just as a mythical hero, encounters harder and longer challenges as it makes its way down the pipeline. It is not unusual to see pipeline executions that last days. A hardware or a Jenkins failure on day six of a seven-day pipeline has serious consequences for on-time delivery of a product.

• Perform manual interventions: Pipelines cross intra-organizational boundaries necessitating manual handoffs and interventions. Build managers seek capabilities such as being able to pause a pipeline for a human to intervene and make manual decisions.

• Audit runs and debug ability: Build managers like to see the exact execution flow through the pipeline, so they can easily debug issues.

1 Jenkins Extension Points https://jenkins.io/doc/developer/extensions/

2 Jenkins Plugin: https://plugins.jenkins.io/