We release Deployment Manager every Wednesday.
That was a initiative the team adopted a couple of weeks ago and for the last two Wednesdays we have kept to it, releasing version 2.1.6 and version 2.1.8. These updates went really well, so we plan to continue making a new version of Deployment Manager available every Wednesday.
Why? Well, we believe in releasing frequently to give our users valuable enhancements as quickly as possible and to get timely feedback on the direction we are taking the product. We’ve been encouraging releasing frequently as a best practice on this very site; extolling the virtues of keeping the delta between releases small and the risk associated with an individual release low. We’ve also told you that practice makes perfect and that the more often you release the less frightening it is to do so. So, all-in-all it seemed a little hypocritical not to push ourselves to improve on our previous 2-3 week release cadence.
Moreover, we want to be deliberate about releasing frequently, rather than opportunist. An opportunist frequent release process is one where you are able to deploy a given code change reliably and with little overhead, but that you choose to do this when the opportunity arises. That could be when you’ve just fixed a bug, when a feature has been completed or perhaps when ‘all the planets align’ and all your automated tests have finally passed. An opportunist release process results in an irregular release rhythm; sometimes there might be three releases in a week, sometimes one a month. You release when you can.
By taking a deliberate approach to frequent releases with Deployment Manager, we still want to be able to deploy a single change to our users reliably and quickly, but we’d also like to have a frequent, regular release rhythm. The reasons for this are three-fold:
- Firstly, it keeps us honest. In order to achieve our goal, we need to be able to keep our build ready for release continually, because on average we are only 3.5 days away from when we next need to deploy a new version of the product to our customers. We can’t afford for the automated tests to break for any period of time, for a dependency to become incompatible for days or for a new feature to drag on-and-on before it is safe to release.
- We don’t have to think about when to release. An opportunist release process means that you need to continually agonise over whether ‘now’ is a good time to do a release or not. That decision can take time, effort and (possibly) a great deal of thought. Famously, Richard Feynman is said to have had the same dessert every single day when he was a student at MIT. Why? Because “I got sick and tired of having to decide what kind of dessert I was going to have at the restaurant, so I decided it would always be chocolate ice cream, and never worried about it again—I had the solution to that problem”. Agreeing to release every Wednesday means that our ‘when should we release?’ problem is solved.
- Finally, we don’t want to drown our users in updates. We think that one release a week is frequent enough for users to get their hands on the latest work we’ve done and give us timely feedback, without the update notification becoming as popular as Clippy.
Providing you have a trustworthy, repeatable automated release process, great test coverage and bunch of people who really want to get their work out to users quickly, then release frequency should only be limited by the appetite your users have for the rate of updates. So, what do you think about weekly releases of Deployment Manager? Perhaps you feel that our in-page update notification will become a little wearing, or perhaps you can’t find what new features are in a given release? Let us know what you think by commenting on this post.
Although we may change the way users are notified of updates, I’m pretty confident we are going to keep to our goal of releasing Deployment Manager every Wednesday – and now I’ve made that public, we’ve got another reason to stick to it!
Agile development programmes (and by that I mean multiple agile teams working on the same product/suite) use this deliberate release cadence to synchronise updates/development – and someone’s called it the “Agile Release Train”. See the Scaled Agile Framework site for the full details, but I kind of like the metaphor and how it correlates with what we are trying to do on Deployment Manager:
We use the “train” metaphor to communicate a few key concepts.
- The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases)
- It delivers its cargo to customers (Release) or is used for internal evaluation and proof of incremental system robustness and quality (PSI/Release).
- If an Agile Team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content.