What is Continuous Delivery and some common misconceptions about it

What is Continuous Delivery

Continuous Delivery, as defined in the “Continuous Delivery” book by its authors Dave Farley and Jez Humble, is the ability or an organization or team to keep software always in a releasable state.

Behind this simple and elegant definition, there is a significant meaning in terms of what it means to be “releasable”. Fortunately, the book as well as companion content such as Dave Farley’s Continuous Delivery YouTube channel explains in thorough detail what is continuous delivery and what does it means to be “releasable”.

In essence, it means:

• CI is practiced: in particular, trunk-based development or frequent code integration is being done, ideally at least once a day, as defined by Martin Fowler in his seminal CI article.
• Software is verified to be technically correct: unit tests, assembly / unit-integration / system-integration tests, static code analysis.
• Software is verified to be functionally correct: functional tests, UI tests, API tests.
• Software is verified to be secure: static application security testing, dynamic application security testing, software composition analysis, cloud security testing, secret leakage detection, pentesting.
• Software is deployable: at any time and to any given environment, without exception.

As introduced by the authors, a continuous delivery pipeline is therefore the sequence that transforms code into a deployable and verifiable package, performs the necessary steps to deploy and verify it, and ultimately deploy the software package to every environment up to production (may it be through automatic promotion or though manually-approved promotion steps).

A common misunderstanding

It is a common misunderstanding to confuse continuous delivery and continuous deployment. Sometimes you can read that continuous deployment is completely automated (the deploy action occurs after every commit when quality gates pass) while continuous delivery is manually-approved. Other times you can read that continuous deployment is what comes after continuous delivery, that is, continuous delivery is the pipeline up to staging and continuous deployment is the next step up to production. Both interpretations, as well as many others, are incorrect.

By means of the definition of continuous delivery, continuous deployment is part of continuous delivery — it is a requirement to continuous delivery, as it happens with continuous integration or continuous testing, too.

Continuous deployment is therefore more properly defined as the ability to deploy changes to any environment when needed and without human intervention. As such, continuous delivery requires of continuous deployment — to be “releasable” means that the following two capabilities are required:

a) Deploy software to non-prod environments for validation.

b) Deploy software to production environment when the release is done.

The previous capabilities define what does it mean to be “releasable”, regardless if the actual deploy to production action occurs after every single commit that passes quality gates, daily, weekly, or on-demand when the business asks (and/or approves) for it.