Continuous Delivery Vs Continuous Deployment

A number of customers I talk to about Continuous Delivery say they have no intention of deploying to the production without proper approvals.

The nay sayers often use the “won’t work for us” excuse.

“Broken Facebook feed causes you inconvenience. Broken checking account could destroy your life.” say IT workers of any bank.

They have a point. However, I wasn’t talking to them about deploying an untested code in production. I wasn’t even talking to them about deploying to production and herein lies the challenge of distinguishing Continuous Delivery from Continuous Deployment.

Continuous Delivery doesn’t propose deploying every change to production. It only proposes that you ensure that every change is “deployable” . 

CONTINUOUS DELIVERY

This means that the developers can’t churn out bug ridden code that is unstable and will most like crash any environment it gets deployed to. It also means that the testers can’t rely on old archaic testing methodologies that involve a lot of testing at the end of the dev cycle but don’t necessarily lead to better quality release! Similarly, the deployment can no longer be a set of manual steps that can’t be repeated unless handed over to “Dan on 6th floor who is out sick today”.

Continuous Delivery relies upon automation (and not the traditional automation).

Continuous Deployment, on the other hand, asks us to boldly go where many have gone before – to the world of automated deployment all the way to the production.

CONTINUOUS DEPLOYMENT

Continuous Deployment is the next step to Continuous Delivery. Once you have established good automated processes to develop, test and deploy every code change in production like environment  within acceptable quality threshold, you can take the plunge and auto approve for deployment to production.

Neither Continuous Delivery nor Continuous Deployment is about swashbuckling developers deploying half-baked  ideas to production. On the contrary, it is about highly disciplined teams that are mature enough to communicate with each other, committed to standing behind their work to deliver high quality (not just well tested) software for end users.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *