At the beginning of the month, Redgate sponsored Talk UX. Revathi and I went to Manchester to attend it, and we’ve been talking about it to whomever wanted to hear. These are some of the questions we have been asked, here is what you’d have heard us say if you were there too… How was […]
This post was first published on the futureofdeployment.com blog. Future blog posts from the team on deployment and continuous delivery will appear on the Redgate blog in the DLM category.
The team I work with release 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 believe in keeping the delta between releases small and the risk associated with an individual release low. We think practice makes perfect and that the more often you release the less frightening it is to do so.
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, 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.
Some years ago, Redgate founded the Springboard incubator for start-ups. We put the word out and got people to apply – if you were successful, we’d give you a bit of money, office space and mentoring. It wasn’t something we’d tried before, so Neil Davidson and I did a fair bit of the interviewing. When […]