This post was first published on the 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.

Related posts

Release Wednesdays: Deliberate, Frequent Releases


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.

5 Tips for Achieving Continuous Delivery


If you’re struggling to set up a reliable, repeatable release process you’re not alone. The good news is that most of the problems you’ll encounter have been solved before.

There are many smart strategies you can use to create a fast, smooth release process that will give your entire team a competitive edge.

#1: Version everything

Source control for application code is a given.

Have a single source of truth that the whole team can use.