There is a good chance that you would have had several debates on what is the difference between 'Continuous delivery' and 'Continuous Deployment'. I have spent several hours discussing this with different groups.
Usually, 'Continuous Delivery' implies keeping your software in the releasable state for every commit so that you can push a button and release a qualified candidate to production. In contrast, 'Continuous Deployment' is where you deploy every qualified commit to production. However, what helped me to understand the landscape better is the effort to understand their origins. This was very important as I have heard people argue that only one of these is concerned about delivering value to the end-user/ customer. You will soon find out why that interpretation is incorrect.
Most of us (including me) would have got introduced to 'Continuous Delivery' through the book written by Jezz Humble and David Farley with the title "Continuous Delivery - Reliable software releases through build, test, and deployment automation". They share what they learned from practising continuous delivery in their consulting projects at Thoughtworks.
The term 'Continuous Deployment' was used by Timothy Fitz when he was working at IMVU. You might have heard about IMVU from the book "Lean Startup" authored by Eric Ries. Tim has written about the process of continuous deployment here. He mentions how continuous deployment is deploying every commit to production and the benefits of the fail-fast pattern.
Now we understand that continuous delivery and continuous deployment are two practices that originated at two different places around the same time, with each not aware of the developments on the other side. The consulting teams were working on business applications, and they have the external factors which constrain when the deployment to production can happen (usually decided by the business stakeholders). On the other side, the product at IMVU was a pure tech product, and the dev team had complete control when they could deploy to production. Hence in continuous delivery was push-button deployment was widespread.
The post of Timothy Fitz clearly mentions continuous deployment is shipping your code to customers as often possible. So the argument that continuous deployment does not care about delivering value to customers is just a speculation.
To conclude, in my opinion, we don't need two separate words to differentiate between the level of automation (driven by business constraints). I stick to the word 'Continuous Delivery' to communicate with both technical and business stakeholders. The presence or absence of push-button for deployment is an implementation detail. In my experience, the practice of continuous delivery also evolves with your product. The level of automation increases and you keep improving the techniques through the feedback you receive. At the same time, the goal remains the same - "satisfy the customer through continuous delivery of valuable software(from the principles behind the agile manifesto)".
Links: