Releases Should be Boring

Six times a year, there was a party with ice cream. The release effort spanned multiple projects and was a 36 hour, high pressure marathon. Its successful navigation was a major accomplishment to be celebrated.

Aside from getting a new product out the door, the celebration of a release is a “bad smell”. It tells us a lot: The releases are done infrequently. They are hard. There is risk and fear.

Modern approaches like Agile and DevOps encourage smaller, more frequent and less risky releases. In short, releases should be boring. Really, really boring.

Last Friday, we added a search capability to the main website. It’s really nice. We sent out some “nice job” celebratory emails to the team that researched search tools, implemented and styled the new widget. The marketing guys are really excited.

But, we didn’t celebrate the successful deployment or feel relief that it actually worked in production. Of course the deployment worked, it always works. Of course the functionality worked, it worked in the test lab. The test infrastructure and test deployment processes are so similar to the “real” ones, and so automated that there’s no fear. Our uDeploy stats show less than a 1% failure rate over the last six months – and that was in test.  No hesitation. Releases happen all the time.

We should celebrate new features and better user experiences for our customers. The process of getting that new feature out the door? Yawn.

If you are throwing release parties, or just relieved every time the release doesn’t go wrong, it’s probably time to look into DevOps techniques and automating your releases. It’s not like the business is going to want to slow down the pace.