Over a million developers have joined DZone.

If Releases are Painful, Do Them More Often

DZone's Guide to

If Releases are Painful, Do Them More Often

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

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.

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}