Continuous deployment principles do not fly in businesses where IT/programming departments are considered a cost center. We are seen as 'burning money' rather than 'generating money.' Our opposing view is: without our programs, we would go from 140 employees to 5000-15000 employees to handle the workload.<p>My business's happiness is not about the IT department's happiness. It is about meeting quota. I'm a big fan of TDD (test driven development) stuck in a waterfall.
just deploying every time your tests pass is not continuous deployment. using it in production will only lead to pain down the line.<p>to do it properly you need some or all of the following:<p>a) to be able to deploy to only a fraction of your servers, and expose new version to fraction of your users
b) detect performance degradation
c) detect increase in error rates
d) detect decrease in traffic, user engagement etc.<p>and of course, auto-revert in case any detected problem.<p>somehow I doubt they actually do that.