Micro Focus is now part of OpenText. Learn more >

You are here

You are here

When you must use continuous delivery with continuous deployment

public://pictures/John-Jeremiah-Technology-Evangeslist-HP.png
John Jeremiah Evangelist, GitLab
 

People tend to use the terms "continuous delivery" and "continuous deployment" interchangeably, but they're not the same thing by a long shot. In most cases people are talking about continuous delivery. They rarely, if ever, want continuous deployment, although there's at least one circumstance in which you might use both. That's what I want to talk about here. But let's get those definitions out of the way first.

Continuous delivery

"Continuous delivery is a set of principles and practices to reduce the cost, time, and risk of delivering incremental changes to users... Continuous delivery reduces waste and makes releases boring," says Jez Humble, vice president at Chef and author of Continuous Delivery.

Martin Fowler, chief scientist at ThoughtWorks, offers his definition of continuous delivery:

Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time...You achieve continuous delivery by continuously integrating the software done by the development team, building executables, and running automated tests on those executables to detect problems...[Y]ou push those executables into increasingly production-like environments to ensure that the software will work in production.

You stop there. Until the business requests the change.

The value of continuous delivery lies in the fact that the code is ready to deploy at all times: QA automatically tests every build in each environment, and if it passes, then the code is ready to deploy. Implementing continuous delivery effectively increases quality and velocity and makes the team more efficient.

Continuous deployment

In contrast, continuous deployment means that every change goes through the pipeline, and if all tests pass, it automatically goes into production. With this approach you can have multiple production deployments in a single day, depending on how fast the team is committing changes. Remember, continuous delivery means you can deploy frequently, but the pace of change is set by business demand.

I recommend reading Fowler's entire blog post on the subject, which goes into depth about DevOps culture and key indicators of continuous delivery.

In the world of continuous deployment, there's no release approval, there's no change approval board, and the code moves automatically from developer to production.

But in the enterprise, the world of "non-unicorns"—is there a case for continuous deployment? For a long time, I believed the answer was no.

I now believe there's at least one exception—the hot fix.

Exceptions prove the rule

Consider a team that has a continuous delivery pipeline and uses automated continuous testing to rigorously assess each change. After a change is ready for release, it waits until the business is ready to implement (pull) it before deploying.

But when an incident occurs, the team quickly isolates a fix and uses a continuous deployment path that automates the deployment to production. This is reserved for changes that are urgently needed to rapidly restore service or correct a serious problem in production. Still fully tested, as with continuous delivery, this approach would ensure the fastest way to fix a production problem.

From an audit and compliance perspective, there certainly might be concerns surrounding segregation of duties and record keeping. But if this process is well documented, clearly defined, controlled, and audited, then many of those concerns can be addressed.

Continuous deployment can serve as a second path to production, where the final steps in that process are fully automated to install changes that correct a production problem as quickly as possible. All routine changes still go through the continuous delivery flow, queuing up and pending a decision to release. But in an emergency, the team has that fully automated path to production. They're not skipping any steps but ensuring that fixes are quickly tested and implemented. This keeps all the environments in sync and of the highest possible quality.

There may be other examples in which enterprises will want to adopt continuous deployment as well as continuous delivery. What are yours?

Keep learning

Read more articles about: App Dev & TestingDevOps