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.
Back in August 2013, the Redgate development team I work with decided that they will only release their product on Wednesdays. In fact, they decided they were going to release every Wednesday.
We were keen to get away from the ‘opportunist’ release process we had fallen into, where we released whenever an opportunity arose. This had resulted in an irregular deployment cadence and had the side-effect that we were continually agonizing over whether ‘now’ was a good time to ship. Release Wednesdays – our initiative to release every Wednesday and only on Wednesdays – was intended to fix that, while ensuring the product code was still in a constantly shippable state and we didn’t swamp our uses in new version notifications.
So, what happened? Well, since the inception of Release Wednesdays, the team have released the two products they have worked on in that period over 75 times and have settled into a really solid, comfortable deployment cadence.
When discussing our frequent, regular releases I find myself using the metaphor of a train running to a timetable. It helps to communicate a few key concepts of our approach:
- Releases happen on a deliberate schedule
- A release delivers cargo (features, bug fixes, enhancements) to a destination (the users)
- The team needs to get its cargo ready in time for the next scheduled release. If they miss that, then the release will not wait for them and the cargo has to wait for the next scheduled release.
As an aside, this model is often used in a multiple team environment, where a number of development streams need to be synchronised in order to get a release out of the door.
Release Wednesdays are a success!
We’ve found that there are many benefits of this release cadence:
- Users get valuable new functionality sooner – if we feel that users will get value from a partially complete feature (where the ‘complete’ part has been fully tested), a bug fix or a usability enhancement, then we ship it on the following Wednesday.
- We don’t need to do ‘special’ builds – because our next release is on average only 3.5 days away, we never need to do special (a.k.a. private) build to help individual users get around a problem.
- We are better at releasing – we’ve practiced, we trust our automated tests and we’ve streamlined our process.
- We don’t ship broken releases – even though we release much more often than we used to, we have not shipped a release we have had to recall since we started Release Wednesdays. That’s because we’ve kept the delta between releases small and the risk associated with an individual release low.
- We don’t spend time worrying about when we should release – if it is not a Wednesday, we don’t start the release process.
- We are always releasable – we’ve had to organise our development environment so that we are always ready to release. That means using the likes of feature branches, tiered automated tests and continuous deployment into a test environment.
- The team love it – there’s something intrinsically motivational about delivering something you have made to people who will find it useful. Whenever we ask the team what they like about the project, they always mention “Release Wednesdays”
Our Release Wednesdays initiative has been a great success and it’s something that’s proved to be motivational for the team.