Freezing deployments is risky

A piece of wooden board in a bog pond
A log in a bog.

If you’re running mission-critical software, how do you minimize the risk of it breaking during these difficult times? Releases cause problems, so it can be tempting to require an approval of each release by a change advisory board. You could even declare a deployment freeze: no new versions of the software can be deployed unless absolutely necessary.

Releases are inherently risky and a freeze does reduce this risk by making the releases rarer. On the other hand, it makes the relases even more risky than usual by making them bigger. Because releases become rare and it’s hard to get an approval, people will cram as many fixes and features as they can into each release

If you start with a reasonably reliable release process, I believe that making releases bigger and rarer causes more problems than it solves. The Accelerate State of Devops Report 2019 concurs. They write about heavyweight change processes (pp. 50-51):

We found that formal change management processes that require the approval of an external body such as a change advisory board (CAB) or a senior manager for significant changes have a negative impact on software delivery performance.

According to their research, the heavyweight processes increase change fail rates. They conclude that “Analysis suggests this approach will make things worse.”


Comments or questions? Send me an e-mail.