Engineering in Focus

One of the benefits of continuous deployment that I didn’t fully appreciate until I was actually doing it is how much it allows you to cheat elsewhere in your development process without doing much damage. Yes, that’s a good thing. Continuous deployment does take a lot of skill and discipline, but investing there makes a lot of things easier upstream and downstream. Like Luther, be a sinner, and let your sins be strong, but believe in agility more boldly still!

Continuous deployment, a.k.a. continuous delivery, has been described in detail elsewhere. The point here is that your code is thoroughly tested, your deployment is automated, your production environment is monitored, and you develop in small increments on the trunk so that you’re never more than a few minutes away from releasing a new version to production. If so, then let yourself go:

• Don’t worry about bugs. If a bug makes it past your acceptance tests it’s not likely to cause serious damage, your monitoring will detect it quickly and you’re going to be able to fix it and roll out the fix in no time, without causing regressions.
• Go easy on performance optimization. Most features will change beyond recognition before they get used enough to need performance tuning. If it’s fast enough to make users happy, and you know you can make it faster soon enough if you need to, go ahead and roll it out now.
• Go ahead and hard-code. If it were going to be two weeks until your next deployment you’d need a back-office interface for changing every piece of data that might need to change by then, but if you’re going to deploy more often than any of the data changes, why bother? Just change it in the source code. And you can let the intern do it; if they make a mistake, the tests will catch it.
• Developers can write all the copy, whether they can write or — probably — not. Your editor can review the copy in production, and any changes can be made in a later deployment as fast as is necessary. Meanwhile, developers will get better with practice.
• Don’t kill yourself trying to design a feature perfectly the first time, or have every bell and whistle you think you might need in the first release. Get it out there, monitor usage, and follow the users. When they tell you what you should have done in the first place, you can do it quickly.

You get the idea. I’m not suggesting that you deploy a change that you don’t think is a good idea, but when the path to fixing a problem is so short, it’s not a problem, it’s just an experiment.

Notice, though that I didn’t say that continuous deployment forgives you all your sins. If your tests or your monitoring are inadequate, and you deploy a serious bug to production, you will be swiftly punished. If you tolerate duplication or unclear code, your application will stiffen and die a slow death. And you do need to think ahead for some changes: if there will be no way as designed to scale a feature quickly once it’s in production, don’t release it until you’ve worked out how to scale it. But your continuous deployment process is your best friend. Take good care of it and it will take good care of you.