Once upon a time, a developer would spend a few months building a new feature. Then they’d go through the gargantuan effort of “integration”. That is, merging their changes into an upstream code repository, which had inevitably changed since they started their work.

This task of integration would often introduce regressions, bugs, and in some cases might even be impossible or irrelevant, leading to months of lost work.

Then, probably in the 1990s, someone had the bright idea of doing integration continuously. This reduced the integration risk substantially, by minimizing, and frequently completely eliminating, the code drift that happens between the mainline branch and an in-progress feature.

This continuous integration was greatly aided by the now ubiquitous automated test pipeline, which helps ensure that each incremental change doesn’t introduce unintentional behavioral regressions.

Then, starting around 2009, we started hearing about Continuous Deployment and Continuous Delivery, which as a concept, are “in essence the principle of continuous integration [pipelines] taken to its logical conclusion”, according to authors Jez Humble and Dave Farely in their important book Continuous Delivery.

Traditionally, most organizations tend to follow this same chronology when implementing Continuous Deployment, as well.

They start by building an automated test suite, then putting them into a pipeline that runs for every code change. Some time later they’ll start doing automated builds, perhaps nightly at first, then eventually for every code change. At some point in the future, when they’re confident that their entire pipeline is reliable, they’ll start deploying these builds into production automatically. Finally! Achievement unlocked! Continuous Deployment

I think this is unfortunate.

While Continous Delivery and Continuous Deployment are logical extensions of Continuous Integration, that doesn’t mean they need to be chronological extensions.

That is to say, I believe it’s not only possible, but completely reasonable to start doing Continuous Deployment before you have a complete, reliable test automation system in place.

To be sure, every high-performing team will aim to automate testing, but that doesn’t need to be the starting point. And often, it shouldn’t be. If your team is waiting for automated tests to be complete and reliable before taking the next step toward Continuous Deployment, you could be waiting a very, very long time. Perhaps forever!

In my free Lean CD Bootcamp, I walk you through the steps to get to Continous Deployment as quickly as possible, even while continuing to rely on manual QA acceptance testing, if that’s what you’re doing today. With Continuous Deployment in place, it can actually be easier and safer to make the remaining transition to automated acceptance testing.