"An Informative Build is a build that tells us what the state of our development is so that we can make an informed decision. We need an informative build, because otherwise Continuous Integration is just a waste of our time.

That’s right, I said Continuous Integration is a waste of time. It is a waste of time, because simply running a build doesn’t help us unless that build can also tell us what we need to do. An Informative Build:

Fails when something is wrong, letting us know that our system is broken and we must fix it.
When it fails it tells us precisely why it failed so that we know what we have to do to fix it.
When nothing is wrong it doesn’t fail. We shouldn’t be wasting cycles chasing down errors due to brittle tests or external dependencies."

"So what should Alex do? Continuously deploy. Every commit should be instantly deployed to production. Let’s walk through her story again, assuming she had such an ideal implementation of Continuous Deployment.
Alex commits. Minutes later warnings go off that the cluster is no longer healthy. The failure is easily correlated to Alex’s change and her change is reverted. Alex spends minimal time debugging, finding the now obvious typo with ease. Her changes still caused a failure cascade, but the downtime was minimal. "

"Assuming you're with me so far, what will that mean in practice? Throwing out a lot of code. That's because as you get better at continuous deployment, you learn more and more about what works and what doesn't. If you're serious about learning, you'll continuously learn to prune the dead weight that doesn't work. That's not entirely without risk, which is a lesson we learned all-too-well at IMVU. Luckily, Chad Austin has recently weighed in with an excellent piece called 10 Pitfalls of Dirty Code."