Continuous Deployment - Neat Idea, but not generally applicable

Continuous Deployment, as I interpret it from this particular article, is basically automating your production pushes to come straight from your Continuous Integration environment with NO human intervention in between. I will leave it to you, the reader, to check out the full article before continuing reading my post.

To paraphrase the author, this method of development involves building and testing all commits in your Continuous Integration environment followed immediately by an automated deployment in to your production environment automatically, and that such a methodology actually encourages very strict and rigorous automated testing and discipline from developers. I believe him. It is a lofty goal and is an extremely neat concept. There are cases where I'd probably see myself recommending and implementing such an approach - think of a smaller start up with limited resources whose production systems don't necessitate 24x7 availability or correctness according to a specification (perhaps Twitter in the early days?).

However, in the general case, I don't know if Continuous Deployment is such a wise goal - at least to a production system. I for one don't even encourage it in my own shop to our development environment since I want to maintain some semblance of stability in that environment where deployments are timed and roughly scheduled simply due to the number of disparate groups who rely on them for testing and working on their own components and systems (this is a side affect of an SOA architecture). Continuous Integration encourages constant integration somewhere, which means deployment ought to be happening somewhere for automated integration testing - to me that environment shouldn't be to your production environment. I for one think that automated deployment followed by automated integration testing should be segregated from live environments consumed primarily by humans, be they developers, testers, business users, or external users/customers. Most organizations have environments containing specific versions/combinations of their systems, each with different roles according to their development process. Updating one automatically at the point in which any developer makes a commit is too loose for an organization of larger size with many systems and many teams where there is usage and testing (manual or not) of a given environment going on seemingly at all times.

That's not to say that deployment shouldn't be automated... it should. But the ability to deploy, in the general case, should be held in escrow by a human to at least enact a deployment on a push button basis. Otherwise, I believe too much burden (that being almost all) falls on the developers for owning deployments to an environment - a task they should be mostly decoupled from.

There is something else that rubs me wrong about Continuous Deployment. There aren't multiple validation factors being applied to the sanity of a given build. Automated testing, be it unit/integration testing at build time or monitoring via an alert system (e.g. Nagios) is indeed quite awesome, but it shouldn't be the only check. Automated testing, much like manual testing, is fallible because it too is ultimately orchestrated by humans (someone has to write those tests!). One method of testing by itself can't be trusted - I have seen it all too often where an automated test picked up what QA guys did not catch (or picked it up much more quickly) and when QA guys spotted failures that the automated tests did not account for. Going full hog on Continuous Deployment gives you a single point of failure on testing, and in my honest opinion, is no more reliable than manual human testing by itself where correctness is concerned.

Again to summarize I think Continuous Deployment to production is a neat idea and applicable in certain cases - but I wouldn't suggest getting all hot about it unless you are willing to accept the risks it might bring with it to your organization.