One of the cool things about continuous deployment is that rush of, "Here's a new feature, right now! You don't have to wait! It doesn't break any specs, so it

One of the cool things about continuous deployment is that rush of, "Here's a new feature, right now! You don't have to wait! It doesn't break any specs, so it must work and be a good idea!" One of the downsides is that bugs like this creep in, because there's no QA step. (and code review is not QA). So, push something that accidentally breaks the app? Oops. The good thing about a continuous deployment strategy is that the engineer can turn around right away and push a fix. Low ceremony helps here, "Oops, forgot to add this file to the source repo" can be fixed fast. I've been with clients where a "continuous deployment" strategy would have meant, "continuously putting out fires, throwing any idea of development process out the window". But, Nick said his job was essentially dev support of QA, where you might not want to wait for the next two week iteration to schedule a ticket to fix a bug in production.