Continuous Delivery doesn't mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time
— Carl Caum (@ccaum) August 28, 2013
I tweeted this out around the middle of the day last Wednesday. It kicked off an active conversation on Twitter, and by 5:00 Thursday, it had been retweeted 87 times, and favorited 25 times.
What It Is & How to Get Started
» Smoother deployments.
» Happier teams.
» A more agile business.
Clearly, it’s a hot topic, and there’s some confusion between continuous delivery and continuous deployment. It’s worth spending a few more characters than Twitter allows to define these terms.
Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready.
@ccaum @steveburnett I think many people confuse "Delivery" with "Deployment".
— Magnus Hedemark (@Magnus919) August 29, 2013
Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.
There are business cases in which IT must wait for a feature to go live, making continuous deployment impractical. While application feature toggles solve many of those cases, they don’t work in every case. The point is to decide whether continuous deployment is right for your company based on business needs — not on IT limitations.
While continuous deployment may not be right for every company, continuous delivery is an absolute requirement of DevOps practices. Only when you continuously deliver your code can you have true confidence that your changes will be serving value to your customers within minutes of pushing the "go" button, and that you can actually push that button any time the business is ready for it.
Learn More
- Continuous delivery talks at PuppetConf
- Why continuous delivery is good for your business
- Continuous delivery depends on continuous integration — and continuous integration depends on automation
- Continuous integration for your Puppet code
- Read the 2016 State of DevOps Report to learn how DevOps improves IT and business results.
Seems there is still
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
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
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
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
imo the confusion is making everybody confused +1 for peck (agile mindset)
The focus of Continuous
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.
Add new comment