Skip to content

Shipping Software Safely: Don’t Mess with The Release Gods!

To paraphrase the great Alan Partridge, there are three rules when it comes to releasing software safely:

  • Be Lean
  • Be Safe
  • And that’s it.

Or put another way: Don’t Mess With The Release Gods

I am but a simple soul who has spent many years shipping software changes just knowing that something would go wrong somewhere and just hoping that it wouldn’t be so terrible that I would end up getting fired.

I am sure there are many people out there who have been successful with every production release they have ever made.  Probably the same people who have CV’s telling you that all their projects have been delivered on time and to budget.

For us mere mortals however, how can we reach this zen-like state of confidence with our releases?  The answer is Do Not Mess With The Release Gods.

Some examples….

Release Gods do not like big releases with loads and loads of content.  Remember it only takes one line of code to cause disaster.  The probability of that happening increases with release size.

Release Gods do not like you saving up all of your changes for annual releases because, hey you think, this releasing business is quite hard.  You have to do loads of paperwork and convince people that I am not going to mess up.

Release Gods do not like overly clever releases with loads of interdependencies and breaking changes.  Remember if you find it hard to understand it so will they and you will pay the consequences.

If like me recently, you think you can get away with shipping several small independent changes in the same small change window, then think again.  This still adds up to a big release, you are asking for trouble.

Salve The Release Gods

Let’s end on a positive note.  Salve The Release Gods.  They like that.

I cannot think of an example in my experience when making the simplest possible, smallest release backfired.  So do that.

And if you do have to do something complicated, do what a colleague of mine did.   Write and build a set of features (perhaps disposable) that will help you deliver safely (a closed beta site for example) and release those.  In the simplest, smallest possible way.

Think. Act. And that’s it.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *