Problem is that code always breaks in production. What we should strive for is not to cause a critical break that creates massive loss for the company. But code has and will break in production.

Even better is to have an automated immune system that detects production issues and rolls back. We push to production dozens of times a day with dozens of engineers committing, and with that environment, problems will eventually slip through your local tests and buildbot.

Bugs happen; it's far better to focus on robustly dealing with problems than it is to build layers of bureaucracy and process in an attempt to pretend that you can avoid all errors. At my current company, dozens of engineers are pushing to production dozens of times a day. We have an extensive test suite that runs on every commit before code can be pushed to production, but there's always something that slips through, which is why we also have an automated cluster immune system that can automate a rollback whenever any metrics go bad during or after a push.

Bugs happen; life is better if you expect it and plan for it. My philosophy is, break production, and keep breaking it until you're damn good at dealing with production failures. Don't let fear of breaking production slow you down.

There's no better way to learn.