I wasn’t involved with last week’s release. Actually, I left work early to celebrate Swedish Christmas with my family. And the release went ahead without a hitch. Bliss.

I believe that making a release is a core responsibility that should be shared by all members of the team. Anyone should be able to do it, and everyone is accountable for regularly participating in a release to ensure that their knowledge of the release process and the production environment stays current. The release is where the rubber meets the road; it is where our software toils become truly relevant and valuable. It is a shared formative experience for everyone on the team.

As I had been involved with setting up and scaling the system out to the new servers, it was useful for me to sit out this release and let others understand the changes to the environment. Not that I mind.

For this to work, making a release has to be:

  • simple: the release process needs to be simple enough that new team members can be quickly brought up to speed. It shouldn’t require much in the way of specialized skills or knowledge. It should also be simple enough to be relatively mistake-proof. The more complex the process, the greater the chance of error.
  • fast: the longer that it takes the release to complete, the greater the risk of failure or outages. It also puts more of a burden on the team, especially if releases are required outside of core business hours. Fast releases are easy to do more frequently and are generally easier to recover from.
  • automated: the more of the release process that is automated, the simpler and fast it becomes. Currently our release is a mixture of automated and manual steps. Automating as much as possible is an ongoing process.
  • documented: ensuring that the process is documented, especially for those steps that are not yet automated is essential. Good documentation (we use our wiki) ensures that the process is consistent and complete. It also provides clear guidelines as to what should next be automated.
  • safe: we strive to ensure that all parts of the release process are reversible. If there are any unexpected problems with the latest version we can easily revert to the previous working version. Reverting should also be automated.
  • paired: releases should be made with the support of other people. When problems arise, as they invariably do, it is invaluable to have someone else to help validate and diagnose problems, keep a level-head and provide guidance. Making a release takes courage and pairing gives us the confidence to do this regularly.

Last week I was reading Eric Ries’ blog. He writes about how at IMVU they try to have new joinees promote code that they wrote to production on their first day. Now that’s something to aspire to.