Continuous Delivery Vs. Continuous Deployment: What's the Diff?

Seems there is still confusion. What you are calling Continuous Deployment would be, as far as I have understood it, what Jez Humble and David Farley call "Continuous Release". In their book

http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison…

As an example hardware companies can to Continuous Deployment (to a piece of test-hardware) and that can help them a lot, even though they only release a new piece of hardware once a year.

For example a SaaS web-application automatically deploying to production (as in your illustration), would be doing "Continuous Release".

The confusion seems wide spread, even Fowler tends to call it "deliveries to production": http://martinfowler.com/books/continuousDelivery.html
Whatever the name though, I think you'd want to deploy/release to a staging or test environment even if you do not go all the way to production. This will not only test your release package but also enable further acceptence tests which should be part of the automated pipeline setup.
Maybe we should call it "Continuous Production Rollouts" or something with the word production in it.

The source of the confusion is that your label does not encapsulate your concept. "Continuous Deployment" implies that you are continuously deploying, which you are not. "Continuous Release," as defined in the prior comment, suffers from the same problem as you are not continuously releasing your code, you are just reducing the number of buttons you push when you're ready.

Why not call it what you really mean? Something along the lines of "Continuously Production Ready"? The key idea being that you are always production _ready_, but not necessary headed to production at the moment. It even gives you a nice initialism of "CPR" -- Put your development cycle on CPR!

best advice is to just define what terms mean with your client. who cares what it's called as long as you get what you expect.

imo the confusion is making everybody confused +1 for peck (agile mindset)

The focus of Continuous Delivery must be on Efficiency of the delivery process and Quality of working Software. And the focus of Continues Deployment must be on the frequency and speed of the deployment of working software on production.

From Business users perspective, there is no value addition if we deliver low quality working software with frequent deployments on production and reverse is also true. That is, there is no value addition if we are not frequently delivering quality working software into the production. Hence the right balance between Quality of Working Software and Speed of Deployment is required.

Hence using Continuous Delivery , we can focus on building quality working software and making the delivery process more repeatable with maximum automation and using the Continuous Deployment, we can focus on increasing the frequencies to release on to the production based on the business needs.

Much more important than the difference between Continuous Delivery vs. Deployment is the difference between Deploying en Releasing. Decoupling these two is what enables the business to make functionality available to users whenever they want to. As stated in the article, feature toggles make this possible. And yes, there are cases where this does not work. I'd say that only in those cases the difference between both CD's is important! 

Continuous Delivery Vs Continuous Deployment , I did a lot of study on this just to figure out the difference , and finally concluded that continuous delivery means that you product is always ready to be deployable to production systems , it is increasing the confidence that your software is production ready. Continous deployment is the same as described above , fully automated pipeline from start to deployment. So one thing you can think of here is the pull vs push model. In Continuous deployment you keep on pushing to production continously , in continuos delivery , it is production ready that can be pulled to production systems any time. 

Published in 2013, this is still one of the best explanations of the difference between in Continuous Delivery and Deployment, especially the process visualization (although it looks like Yassai Sundman gets the credit for the graph). We have even made our own variation for a blog post illustration: https://buddy.works/blog/how-set-up-continuous-delivery-for-nodejs

However, the conclusion from the article should be that CI/CD should be an essential part of every developer's workflow, ideally supported with proper tooling.

Thank you for sharing! I think it's so important to clearly outline the difference between continuous deployment, continuous development, continuous integration, and continuous delivery along with the benefits to your product's quality (but also the cons/resources required). I'll be adding this to my reservoir of resources along with this guide that's been helpful: https://deploybot.com/blog/continuous-delivery-deployment-and-integration-explained

Please, stop telling people that "continuous deployment" is the automation of "continuous delivery". This is simply not true.

The definition of Jez Humble clearly states that the aim of Continuous Delivery is "to put the release schedule in the hands of the business, not in the hands of IT". -- This has nothing to do with "manual" or "automatic". Giving business the power to release whenever they want is much harder than making things happen automatically. Try it to understand!

Continuous deployment is a technique, Continuous Delivery is a concept. If we try to compare the two we're comparing apples with bananas. One is "automate releasing software changes", and the other is "Agile software development" (see the first principle of the Agile Manifesto [¹]).

[¹] http://agilemanifesto.org/principles.html

Hello there,

we are moving from continuous delivery to continuous deployment but we are facing some frictions regarding demos. Using continuous deployment systems makes the Sprint demo a bit awkward as demoed features have been already deployed on production Did any of you faced this kind of issues? Do you deploy to production without PO validation?

Best regards.