A brief history of CI/CD
Tags: cicd, continuousdeployment, continuousdelivery
Published: 2021-09-29 16:26:53

---
title: A brief history of CI/CD
published: true
date: 2021-09-26 00:00:00 UTC
tags: cicd,continuousdeployment,continuousdelivery
canonical_url: https://jhall.io/archive/2021/09/26/a-brief-history-of-ci/cd/
---

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](https://en.wikipedia.org/wiki/Continuous_integration#History), 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_](https://amzn.to/3o80E15).

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](https://leancdbootcamp.com/), 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.

* * *
_If you enjoyed this message, [subscribe](https://jhall.io/daily) to <u>The Daily Commit</u> to get future messages to your inbox._