One of the most perplexing discussions I’ve had in recent times was about CI/CD. I’ve earned my CI/CD scout badge at this stage in my career, so the confusion caught me off guard. This post briefly sets out what Continuous Integration (CI) and Continuous Delivery (CD) mean and addresses the most common misconceptions in the discussion.
My point isn’t just semantic. These terms carry decades of hard-won engineering practice, and when we let their meaning drift or decay, we lose crucial wisdom.
Continuous Integration
Continuous Integration is well named compared to many concepts in our industry. The term “integration” refers to merging your changes into the main branch in version control, and the term “continuous” means you do it often. When Kent Beck popularized the term in Extreme Programming Explained (1999), he set an upper limit of a day. After 26 years of progress, you should expect to be doing it far more frequently than that.
You might understand the concept better if we look at examples that don’t fit the definition. If you have code on your machine that’s more than a day old, you’re not practicing Continuous Integration. If you have a branch that’s more than a day old, you’re not practicing Continuous Integration. It doesn’t matter how often you merge from main into your branch, because main is completely unaware of changes, like yours, that haven’t been merged yet. That means you have diverging software versions, and at some point, you have to make them all converge.
Continuous Delivery
Continuous Delivery is an approach focused on delivering all changes to users quickly, safely, and sustainably. You keep your code in a deployable state at all times and reject the idea of separate integration, testing, and hardening phases. There are specific technical practices involved here because you need a deployment pipeline that reduces risk and increases your confidence that the software version works.
At this stage in our industry’s history, almost everything involved in answering the question “Is this deployable?” should be automated as part of the deployment pipeline. A decade ago, perhaps, you could reasonably list a few stages that were economically unviable for automation. The scale and pace of modern software delivery mean this is rarely the case now.
The simple test is to ask, “Is the software deployable?” If you can’t answer this question every day, you’re not doing Continuous Delivery. In their book on Continuous Delivery (2010), Dave Farley and Jez Humble detail the principles and practices that let you answer this question, and the research has increased our confidence that this is what good software delivery looks like.
Misconceptions
Let’s turn our attention to where the conversation left the trail.
CI doesn’t just mean automated builds
One of the most common sources of confusion is that CI just means automated builds and tests. While it’s difficult to practice Continuous Integration without automation, the crucial property of Continuous Integration is that all changes are in a shared mainline, not on developer machines or in long-lived branches. Having more than 3 branches or keeping branches open for more than a day slows delivery throughput and makes the software less stable, as reinforced by long-running research.
There’s a human process at the heart of CI: each developer chooses to commit their changes frequently to main. Without people deciding to do this, there is no CI.
CI doesn’t allow feature branching
There’s a misconception that you can do CI and choose a branching strategy, like feature branches. Any branching strategy that keeps a change out of main for more than a day cannot be called CI. You may still choose to use feature branches despite the drawbacks, but you have to stop calling it Continuous Integration, as you aren’t continuously integrating all changes.
CD doesn’t mean Continuous Deployment, though it can
CD means “Continuous Delivery”. It means your software is deployable at all times, and you can test this daily by asking, “Can we deploy the software?” If you don’t have a way to answer the question confidently, you’re not doing Continuous Delivery. You may choose to deploy every validated software version automatically, which is Continuous Deployment, or you may need to be more tactical about when you deploy. Either is fine.
For both Continuous Delivery and Continuous Deployment, you need high levels of automation and sufficient risk coverage within that automation so you know you can deploy. Continuous Delivery should mean you can deploy at the press of a button, and Continuous Deployment removes the requirement to press the button.
You can’t do CD without CI
Some folks were confident that you can do Continuous Delivery without doing Continuous Integration, but the literature on this is very clear. Farley and Humble explicitly include Continuous Integration as a required practice. There’s a whole chapter dedicated to it (p. 55 of Continuous Delivery) that adequately explains how it should work and why it’s not optional.
CI/CD isn’t vague or open to interpretation
Another claim that came up more than once was that CI/CD is vague, open to interpretation, or lacks the detail on “how” you should apply the approach. This does a disservice to those who conscientiously captured the approach, whether that’s Kent Beck describing Continuous Integration in Extreme Programming Explained (1999) or Farley and Humble detailing both Continuous Integration and Continuous Delivery in their book Continuous Delivery (2010).
Resist the diffusion
There is a constant temptation in the tech industry to allow semantic diffusion to erode our progress. When we package up a cartload of wisdom into a term, we have to resist the diffusion that follows when people oversimplify our term, remove crucial parts of the whole, or try to brand something with the label that pushes us backward.
We have a history of giving up on these battles, as we seem to have done with Agile and DevOps. These terms had an important meaning that represented a significant step forward for our industry, and losing our energy in their defense lets the perpetual “Late Majority” and “Laggards” (from Crossing the Chasm) drag us all back into their old ways.
CI and CD deserve better.
