Back in the Jurassic period of the Internet (also known as 2000 A.D.), Joel Spolsky created the now-popular Joel Test: 12 Steps to Better Code. This test made a big impact on my career as a software developer. But one of the items on the test now seems laughably dated:

2. Can you make a build in one step?

At the time, a one-step build was a pretty novel idea. I remember spending hours manually copying files into place, running various make commands, zipping things, creating MD5 sums, and uploading to an FTP server, to produce a “release” of our application. The idea of putting all of those steps into a single script seemed strangely foreign at the time.

Nowadays it seems blasé.

Any project with a manual release process is likely to be ridiculed, if not by the people actively working on the project, at least by anyone who hears about the project second hand. If you work on a project with a manual release process, I’m sure it’s not something you brag about to your techie friends over a beer!

But what about going one step further, from automated builds to automated deployments, more commonly referred to as Continuous Deployment (CD)?

Most people I talk to agree, on principle, that CD is a good goal. But some are skeptical that it’s worth the effort. In this article, I want to spell out the four main benefits I believe continous delivery can provide to any modern software team.

What are CI, CDE, and CD?

Before I dive into the meat of the matter, let me define three related terms, so there’s no confusion about my meaning:

Continuous Integration (CI)

Broadly speaking, CI is “the practice of merging all developers’ working copies to a shared mainline several times a day”. By extension a “CI Pipeline” (often shortened, simply to “CI”), is a set of scripts that execute various tests against every change, as it is made to the codebase, to prevent breaking changes from being merged into the mainline. This is typically where linters, unit tests, integration tests, and end-to-end tests are executed.

Continuous Delivery (CDE)

CDE (frequently called simply “CD”, and thus easily conflated with Continuous Deployment) is the practice of continuously and automatically delivering a software package. Typically this is done immediately after CI, so that as every change is merged to mainline, a completed software package is produced, and ready to be deployed. This is the automated extension of Joel’s “one-step build”.

Continuous Deployment (CD)

CD takes CDE one step further, by not only building the complete software package automatically, but also deploying it to production servers. With CD, code changes are typically visible to end-users of the software within minutes.

The Advantages of Continuous Deployment

There are many advantages that CD can bring to a software project. I could write pages on this topic (in fact, I already have), but let me summarize some of the biggest advantages that CD can bring to a team:

1. Faster software delivery

This is, of course, the most obvious advantage. If you don’t have to wait weeks or months for the next “release cycle” to complete, you and your end-users can begin experiencing the benefits of your new features much sooner.

2. Faster feedback

With CD, a developer or product manager must only wait a few minutes to see the result of a change. This can help catch bugs faster, as well as to reduce the feedback loop for user-facing changes. There’s nothing more painful for a developer to hear that some code change they made introduced a bug—6 weeks later! The process of re-investigating what they were doing (and possibly what other developers did to the same code in the meantime) can be difficult and cumbersome. It’s much better to discover that same production bug 20 minutes after merging it, rather than waiting for an arbitrarily long release cycle to complete.

3. Reduced risk

Prior to CD, most software updates were done with “Big Bang” releases. All the work of the development team is bundled into a new release called “3.1”, or whatever. This approach is inherently risky, because when something goes wrong, it’s often difficult to determine which of the last 3 months worth of changes lead to the problem. This problem is so prevalent that it has led to the common notion that “.0” software is unsafe to use in certain situations. Every software release contains some risk, but the risk increases exponentially, not linearly, as it is put off. If it hurts, do it more.

4. Improved responsibility

Every developer I’ve met (myself included) has a tendency to be overconfident. I just know my code has fewer bugs than everyone else’s, despite all evidence to the contrary. CD doesn’t solve this problem, but it helps, by forcing a change of attitude. Without CD, it’s easy for the developer to think “If there are any bugs in this code, we’ll find them before we release” (this is especially true with dedicated QA teams). But with CD, the developer knows that when he hits that Merge button, his code will be live, in front of customers, within minutes. This adds a certain healthy psychological weight to the action of merging, which can improve a sense of ownership, and ultimately code quality.

Not convinced?

There are many reasons people resist continuous deployment. I invite you to read my email series addressing these reservations, 10 Reasons Not to Use Continuous Deployment (And why most of them are wrong).