I have looked at "Continuous Deployment: The Dirty Details" by Mike Brittain in SideShare posted on Jan 29, 2013, and found 3 nonsense cases in this overall good presentation.
1. Presentation states, "Architecture largely does not matter" while deployments a claimed every 15-20 min. It is an obvious absurd for monolithic Web applications (as the most of them are) because any change in such an architecture requires regression testing that, depending on the internal logic of the application, may take days in spite of an automation.
That is, an architecture does not matter if the change does not matter. Otherwise, it is the very architecture of the Web application that define granular composable and independently changeable services/components for a rapid delivery and this has nothing to do with code development and delivery itself.
2. "Automated test after deployment". This is not a new type of testing and only I know about it for about 15 years already. However, for all these years nobody came with an idea to expose not-tested product (each new deployment makes running product changed; saying that Deployment ≠ Product is an absolute marketing buzz) to the consumers. In my practice, deployed but not tested products were placed into so-called quarantine where consumers could not access it. How one can really deploy a change in the live Web application and restrict access to it until testing is done in the public Web? Are we going to throw away all our experience in SW development because some new developers want (finally) to put their hands into the production environment?
3. "Your assumptions will be wrong once you've scaled 10x" This is a classic warning for those who jump into coding right away - as Mike recommends - or if architecture does not matter. Any experienced Architect, especially Service-Oriented Architect (and only services can deliver multiple independent deployments at once by the definition of services) knows that the OASIS RA for SOA standard requires to provide a default scalability of 300x. Developers do not know about this and consider such requirement a waste because designing and constructing such scaling capabilities is much more complex and time consuming task than to scrabble a code in a hap-hazard manner and deploy it (for the consumers to suffer).
I see that Web development is trying to get out of hands for the sake of making developers an unavoidable part of the products (while there is a strong flow of replacing development by integration of available services in the Web and Cloud).