Timothy Fitz’s blog entry on continuous deployment came out over a year before Dave and I published our book on continuous delivery. So why did we choose a different name? Is there actually a difference or are we just being bloody-minded?
We decided to call the book Continuous Delivery for a few reasons. First of all, there’s the somewhat pedantic fact that deployment does not imply release. As we say in the book, you can continuously deploy to UAT – no big deal. What makes continuous deployment special is deploying every change that passes the automated tests (and optionally a short QA gate) to production. Continuous deployment is the practice of releasing every good build to users – a more accurate name might have been “continuous release”.
While continuous deployment implies continuous delivery the converse is not true. Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle – that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes.
This in turn relies on comprehensive automation of the build, test and deployment process, and excellent collaboration between everyone involved in delivery – developers, testers, DBAs, systems administrators, users, and the business.
In the world of continuous delivery, developers aren’t done with a feature when they hand some code over to testers, or when the feature is “QA passed”. They are done when it is working in production. That means no more testing or deployment phases, even within a sprint (if you’re using Scrum). If you’re using Kanban and you want to do continuous delivery, you can’t bring a new story into play until the one you’re working on is released to users.
However it doesn’t always make sense to release every good build to users. In particular, this is usually impossible for embedded products when there is coupling between a software change and a hardware change. In the world of COTS, there are good marketing and support reasons why you’d not want to have more than a few “released” versions of your software in play at any given time (although you could still do regular “developer” or “early access” builds as Eclipse and the Omni Group do). There are probably other good reasons too – the important point is that they must be business reasons.
So when can you say you’re doing continuous delivery? I’d say it’s when you could flip a switch to go to continuous deployment if you decided that was the best way to deliver value to your customers. In particular, if you can’t release every good build to users, what does it mean to be “done” with a story? I think at least the following conditions must apply:
- You have run your entire test suite against the build containing the story. This validates that the story is delivering the expected business value, and that no regressions have been introduced in the process of developing it. In order to be efficient, that means having comprehensive automated tests at the unit, component and acceptance level.
- The story has been demonstrated to customers from a production-like environment. Production-like means identical with production, within the bounds of reason. Even if you’re deploying to an enormous cluster, you can use a technique like blue-green deployments to run a different version of your app in parallel on the production environment without affecting users.
- There are no obstacles to deploying to production. In other words, you could deploy the build to users using a fully automated process at the push of a button if you decided to. In particular, that means you’ve also tested it fulfills its cross-functional characteristics such as capacity, availability and security. If you’re using an SOA or you have dependencies between your application and other systems, it means ensuring there are no integration problems.
[...] Se plays a large part in Continuous Deployment setups, but what I am really interested in is Continuous Delivery. Jez (who literally wrote the book on it) explains the difference between the two. [...]
One of the other good reasons one might not want to deliver a new version of the product is the cost-of-change in the mindset of its users. They might not be able to cope with a fast pace on changes in its UI or features. While some groups adapt themselves better with a steady pace of delivery in new features, others react better to batch updates.
Either way, deployment should be subject to business, as you mentioned: in the end, our job is to deliver what our business need, not the other way around.
Great post…
Just a note, when using a limited WIP, one might be able to start a new story in order not to waste effort while waiting for some answers/tests in another one, so can’t one change to the next story if the story is approved to come into play, but did not yet due to a business restriction? (e.g. waiting for the right marketing time, a monday morning)
What’s the point on having a user story ready to be used if it is not going to be used, isn’t it a loss of resources?
Nice article!
Thanks for an interesting and helpful article. How about some links to Amazon UK, FR, DE etc? I may well buy the book, and I’m sure I’m not the only European who’d be happy to earn you some commission.
great article.
“Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT.” — what is a release (respectively its schedule) that is not driven by business?
Nice post.
Have you looked at the value to the business in being able to decouple the application from the underlying technology?
Most enterprise apps are stuck on the platforms that they were first implemented on because the cost of migration is too high. Since the average life of an app is 7 years and most IT shops overprovision, this is a big (if largely hidden) cost.
Seems like even in this article Continuous Delivery and Continuous Deployment get confused sometimes.
Semantics aside, this book is a seminal work and the rallying point for a new community of proactice. INHO, Continuous Delivery is the way forward.
I’m going pull out my poetic licence and enter a new term into the lexicon, *prologue* (the opposite of a backlog). Essentially an status board with accrued Stories/Value awaiting the business upon which they can hit-the-button if there are one or more items in it.
I would however challenge a core notion that *continuous delivery means making sure your software is always production ready throughout its entire lifecycle*. The *only* production ready software is the software sitting in UAT/pre-prod after it has passed it’s quality gate. Sure compile code might *potentialy, ultimately* get released but I’m sure not saying it’s production ready until my system tells me it is.
So, can we deliver value as fast as the business can consume it? Today maybe given legacy cultures but soon, I doubt it. once the Business learn to trust CD, they will hit the button as soon as they can, every time. In fact we’ll know when we’re earned their trust because they’ll ask you to *automatically* hit the button for them
[...] of working software, we need to get the changes into Production as quick as possible through Continuous Delivery so we can shorten the feedback cycle and so the business can maximize the [...]
[...] very expensive to rev hardware. These arguments are the reason why I am very careful to distinguish continuous delivery from continuous deployment. Continuous delivery is about keeping your systems production-ready throughout development, so that [...]
[...] very expensive to rev hardware. These arguments are the reason why I am very careful to distinguish continuous delivery from continuous deployment. Continuous delivery is about keeping your systems production-ready throughout development, so that [...]
[...] the difference Continuous Delivery vs Continuous Deployment (continuous release) As we say in the book, you can continuously deploy to UAT – no big deal. [...]
[...] I received an email from Martin Fowler about this post. He refers to Jez Humble’s post on Continuous Delivery vs Continous Deployment and adds: – I would use your definition of Continuous Deployment for Continuous [...]
[...] We’ve been talking a lot internally about continuous deployment and continuous delivery. Jez Humble has posted a nice blog entry comparing the two. [...]
I want Continuous Delivery for my new team for Christmas.
[...] Deliver finish product frequently in Small batches – Continuous Deployment. [...]
[...] boss to implement continuous delivery. One of the big technical memes of the last year has been continuous deployment – the practice of releasing every good version of your software, often multiple times a day. [...]
[...] very expensive to rev hardware. These arguments are the reason why I am very careful to distinguish continuous delivery from continuous deployment. Continuous delivery is about keeping your systems production-ready throughout development, so that [...]