DevOps Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 74 posts at DZone. You can read more from them at their website. View Full User Profile

Releases Should be Boring

09.24.2012
| 5035 views |
  • submit to reddit

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.

Published at DZone with permission of Eric Minick, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)