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 80 posts at DZone. You can read more from them at their website. View Full User Profile

If Releases are Painful, Do Them More Often

06.25.2013
| 2438 views |
  • submit to reddit

Last week, I had the pleasure of speaking with Stephen Smith (@AgileSteveSmith) at qCon New York. We each presented in the Continuous Delivery track. My slides are here.

Steve’s latest blog, Release More with Less, highlights the power of small patch sizes. I highly recommend it. He points out that shrinking how much is in each release, helps you deliver more frequently, with lower risk, and increased value to the business.

The same adoption challenge as continuous integration

We discussed how resistance to this approach is rooted in pain. If releases are traditionally major events which require heroic efforts and present real business risk, reasonable people will try to do them less often. As Dave Farley (@davefarley77) pointed out in his talk, this is a natural human response. If hitting smashing your head on the wall hurts, do that less.

However, with many business processes this instinct is exactly the wrong thing. In continuous integration, we learned that if integration was “hell” the answer was to integrate continuously. By shrinking the amount of stuff to integrate to something that was very small, the work would be easy.

Agile practices in general have pushed us towards small batch sizes, whether they said so or not. A manifesto line like “Customer collaboration over contract negotiation” encourages us to agree to work on small parts of a system, deliver, evaluate, and renegotiate the next part. Many small negotiations are better than one big one. This leads towards continuous planning, building, and feedback loop.

This brings us back to releasing to production. Releases are so painful because so much is changing. Each change means more work and more risk. Further, because we do them infrequently we are relatively unpracticed, and unlikely to have invested in automation to help. When we commit to deliver more frequently, we will find our manual release processes will become somewhat easier. Fewer changes will be made each time.

So what’s our mantra?

If it hurts, do it more
If it hurts, do it more
If it hurts, do it more

Bringing the business on board

A challenge can be that the business resists the increased rate of change. They may say, “No, we’re fine releasing every quarter.” Frankly, the business has been conditioned to pain, and is also resisting experiencing it more often. Each interaction with development involves a painful negotiation. Releases bring with them risks of outages that hurt. Our partners in the business are also trying to avoid pain by doing things infrequently.

This can be detected pretty easily. When working out plans for the next release, ask the business team, “If you could wave a magic wand, would you want these features live in production right now, or would you want to hold them back until some future date?” Sometimes, they will want to hold them back. Features shouldn’t appear live on the website until a matching marketing campaign is launched. That’s useful information.

More often, if getting a feature was free, the business would want it now. Once the acknowledge that, begin the negotiation around working towards faster release cadence.

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.)