Don’t go digital without continuous delivery

spiral-staircase

Want to succeed in a digital world? You’re going to need agility, agility, and more agility – and that means building your business on an agile infrastructure and using agile software methodologies that include continuous delivery (CD), a technique designed to infuse users’ input and experience.

CD extends the automated testing used in continuous integration (CI) all the way into production environments, where feedback can be captured directly from users. It relies on an automated infrastructure that provides on-demand capacity and API-based integration.

CI is typically implemented as a pipeline where committed code runs through automated unit and integration tests.

CD allows code that passes CI tests to be deployed directly into production. It’s important to note that there’s a deliberate process break so decisions can be made about which version — and hence which features — will be deployed into production. This differs from continuous deployment, where code that passes tests is automatically deployed into production without human intervention.

Large enterprises, particularly those that are regulated, tend to prefer continuous delivery over continuous deployment because the act of deciding which versions to promote into production aligns well with segregation of duties, change management practices, and a general sense of being in control. Continuous deployment is more favoured by consumer internet companies seeking to optimize the speed of their feedback loop regarding new features.

DevOps needs continuous delivery

CI pipelines can be built entirely by development teams. But this can lead to the phenomenon known as deploy to shelf, where engineers complete multiple sprints without their code ever being deployed into production, thus denying themselves of the user feedback that’s essential to proper agile development. If developers do two-week sprints, and operations does quarterly releases (13 weeks), then six or seven sprints will stack up before getting any user feedback.

By extending a CI pipeline into production, it becomes a CD pipeline and crosses the traditional divide between Dev and Ops, and the decisions about which versions get deployed to production happen at the border. The pipeline extension may rely on the same tools as CI, such as Jenkins, or on tools specifically built for CD, such as Spinnaker.

Continuous delivery needs automated infrastructure

CD pipelines use automation that spans dev-test-production, so they need an automated, cloud-enabled infrastructure. There are two important cloud characteristics that come into play:

  1. Capacity on demand – Integration tests are, by their very nature, transient. An environment is spun up to verify something works or fails, and then its work is done. Such activity naturally lends itself to parallelisation, where it’s possible to get quick feedback and queuing as needed, so the maximum number of tests can be run on a minimum-resource footprint.
  2. API-based consumption – APIs connect pipelines to infrastructure. Without them, there are more process breaks, slower flows through pipelines and an overall lack of automation. So-called ticket clouds, where a request for resources becomes a queued ticket requiring action by a human operator, quickly get overwhelmed by the throughput of even a relatively trivial CD pipeline.

Is CD worth the effort?

As organizations advance their DevOps initiatives and consider CD, they may ask whether it provides the necessary resources to ensure that the code being developed is ready to deploy. Does it slow development times because of the need to ensure code is deployable? And is the customer feedback on deployed software worth the effort?

We believe organizations need CD capabilities to be truly agile so, yes, CD is worth the effort. Digital business demands agility at three levels — how the business responds to customer needs, how software is built to meet those needs, and how infrastructure is made available to run that software. CD pipelines let modern organisations connect customer needs to their infrastructure, and that infrastructure must be automated to provide sufficient flow through the CD pipeline.


Chris Swan is a Fellow, VP, and CTO of Global Delivery at DXC Technology. @cpswan

Rob Shear is Principal Global Chief Technologist at Dell EMC. @robshear

Comments

  1. Tim Coote says:

    Hi Chris 😉

    Don’t forget the upside that ThoughtWorks measured of a 40% drop in requirements effort as a result of shortening the release cycles. This arises from the change in behaviour of the business of not throwing every possible requirement into ‘this’ change window as the ‘next’ change window is too far away.

    On the flip side, there’s a lot of technical debt to pay down for existing s/w that’s not been designed to be automatically tested. This is particularly true of packages. But, without paying down this debt, there’s a good chance that digitalisation initiatives will fail anyway.

    Tim

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: