Agreed, getting code into production faster is great and all, but if you don’t have a way to get bad code out of production quickly you might just end up with bad code in production more often. Canaries, well-instrumented applications, and black box metrics that measure the important things are all essential if you really want to promote things easily and without a second thought.

Agree, you need a whole set of tools to go from continuous delivery to continuous deployment.

The most important are reducing the blast radius, early detection, and reducing the mean time to repair.

In GitLab we offer incremental rollouts, auto monitoring, and soon auto rollback to help with these.

If you deploy each change you can't afford to handhold it.

Agreed. If continuous delivery means you can release your software at any time, then that seems to assume you have integrated all the pieces of your software. If continuous deployment means automatically deploying every passing build, it seem to assume that when you get a passing build, you are in a state where you can deploy. So continuous delivery depends on continuous integration and continuous deployment depends on continuous delivery.

I supposed you could just deploy stuff to prod when the build finishes without being in a state where you can safely deploy. Well now that I think of it I have seen places that do that, but it never turns out well.

Continuous deployment means you are never in a state where you cannot deploy. Yes, this requires significant effort. API agility, schema agility, cache agility, ... Lots of things need to be solved! (Imagine storing a serialized cached entity from a later version, abd getting a cache hit in the concurrently operating previous version, for example.)

It's similar to how continuous integration means your master is always stable (all builds work and all tests pass.)

If you can't do a 1% (or 10%) canaried deploy, you're not yet ready for continuous deployment.

Where I'm at it wouldn't really matter if there was 100% code coverage.

I have still to understand how 100% coverage ensures that the product looks good, isn't confusing, does not contain grammar errors and actually implement what the customer wanted in the first place.

Maybe this works well in a company where everyone is great UI artists and who sits with the customers from day 1 until deploy.

Where I work we often think we have a good idea om what we want to implement but after seeing it run we realize we need to tweak some things to make it really good.

Since test suites are never bulletproof[1], you should do continuous delivery anyway. Just wait till you feel they're good enough[2] and try it. Roll out slow / to a limited audience and use the failures to feed back into your testing.

1. What does bulletproof mean anyway? Total coverage? Well tested tests?

2. "Good enough" is deliberately vague and obviously will depend on whether you're writing a game or a HFT application.

CD always struck me as a nitch need that really only applies to a small subset of web services. (I know this is HN but I'm always amused the web developer community seems completely unaware that they aren't the only programmers in the software industry). I imagine for 95% of businesses and products, even web services, having some level of intentionality around the release and someone pulling the trigger is more important.