The Problem with Continuous Delivery: Defining Continuous

"Continuous delivery" is one of the biggest buzzwords of the IT industry today. Thought leaders everywhere are telling developers, admins and DevOps engineers that they should be striving to achieve continuous delivery. But when you sit down and think about what continuous delivery actually means, or how to implement it, the concept starts to become harder to understand.

One major reason is that the word "continuous" in this context is quite misleading. Continuous delivery is not truly continuous, in the sense that application changes are actually continuous in nature. Thus, continuous delivery, like other popular DevOps buzzwords, can quickly become continuously confusing. That begs the questions: What does continuous delivery really mean? What is a practical and realistic pace of updates to pursue within a continuous delivery pipeline? And how can a software delivery team measure whether it’s meeting its continuous delivery goals?

Let’s take a look at some answers to those quandaries.

Defining Continuous Delivery

First, we need to define what continuous delivery means.

In theory, continuous delivery refers to a software engineering strategy in which updates to an application (or whatever type of software your team is building) are applied on a frequent basis.

If you think of the software production process as a pipeline that starts with the writing of code and ends with the deployment of code into a production environment--with code integration, testing and building in between--then a continuous delivery pipeline is one in which the time between the first stage and the last stage is minimal.

Continuous delivery is sometimes defined as the opposite of “waterfall”-style software engineering. The latter involves waiting weeks, months or even years before pushing software updates into a production environment. It also usually entails releasing a large set of updates all at once. With continuous delivery, in contrast, you strive for fast, frequent changes to your application. And because changes are being made nearly constantly, each change is typically very small.

Proponents of continuous delivery contend that it leads to faster innovation, because end users receive updates more quickly. They also usually cite software performance and security advantages, based on the argument that if you can apply an update to your application very quickly, you can correct most problems before they become serious.

For these reasons, continuous delivery--which is often abbreviated as simply CD--has become closely associated with the DevOps movement, which emphasizes rapid innovation and reaction.

Continuous Delivery Is Not Really Continuous

Continuous delivery has many advantages over early modes of software production. I’m not here to knock it. In general, continuous delivery is a good goal for most organizations to strive for.

However, I do think that the IT community would do well to spend more time thinking about what continuity actually means in the context of continuous delivery. It’s easy to say that we want to innovate quickly or push out software changes “continuously.” But it’s harder to define what, exactly, counts as continuous, or how fast innovation should take place.

I’m don't know of any organization that achieves continuous delivery in a literal sense. That would require rolling out software changes as often as every few minutes, which seems quite impossible.

Instead, most software delivery teams that claim to be doing continuous delivery actually apply changes on a slower basis. Once a day is common, although some organizations might apply updates as infrequently as once a week and still think of their operations as continuous.

Thus, the term continuous delivery has always seemed somewhat disingenuous to me to. Something like frequent delivery would seem more accurate.

Why It Matters

You may be thinking that I’m merely splitting semantic hairs by pointing out that continuous delivery is not literally continuous. However, I think that this issue does really matter, for two main reasons.

The first is pretty obvious. By failing to specify exactly what counts as continuous delivery, the IT community makes it harder for organizations to start embracing the concept. That’s because there is no clear goal for them to pursue. If no one can tell you which threshold you have to surpass to start doing continuous delivery, how do you even start? And how do you know that you’re moving toward your goal?

The second reason why we need a clearer definition of continuous delivery is that there is a risk of applying changes too frequently. In some cases, it might not make sense to try to push out application updates more than once a day, or even once a week. For example, significant interface updates that require end users to adjust the way they interact with an application probably shouldn’t be rolled out constantly; if you do that, you risk confusing and alienating your users.

Thus, there is an argument to be made for avoiding too much innovation or too rapid change (or updating quickly and assuming you’ll fix the bugs later). But, because no one has defined what continuous delivery means specifically, it’s easy for software delivery teams to overlook this point and assume that they should always pursue faster and faster updates, even if doing so poses more risk than it’s worth.

Be Continuous in Principle, If Not in Practice

Again, I’m not here to argue that continuous delivery is a bad idea, or that organizations should stick with decades-old waterfall delivery strategies. They shouldn’t.

They should, however, take some time to evaluate just how fast they want to update software before jumping on the continuous delivery bandwagon. No software delivery pipeline is literally continuous, and much of the rhetoric regarding continuous delivery is misleading in this sense.

Ultimately, continuous delivery means an efficient software delivery process that fits the needs of your organization. The definition can’t really be any more specific than that, and any approach to continuous delivery that takes the term too literally is bound to cause more trouble than it’s worth.