Frequent Releases

Agile tells us we should release frequently. Each release generates feedback which we can use to help guide us in what to do next.

In previous posts, I've talked about the importance of staying releasable. Staying releasable gives us options (i.e., allows us to be agile). The closer we stay to releasable, the shorter the list of things that we have to do to release. The shorter that list, the more time we have to do other things. And the more frequently we can release.

But just because you strive to stay releasable after each iteration, doesn't mean you release after each iteration. It just means that you could (or you could after doing whatever is on that short list).

If you release as a hosted service, it is much easier to release frequently. You control the deployment environment. All of your customers can potentially be upgraded at once.

If you release as a customer installed product, it is more complicated. Customers choose when they upgrade. If you released every couple of weeks and supported releases for a couple of years, that could result in over 50 different releases that you have to support!

Even if it is customer installed, you could require your customers to use an automated update mechanism (like Microsoft update). That would put you back into a situation where everyone who is supported is on the same version. rPath is one company who offers a solution along these lines.

If that doesn't fly in your environment, then your next best option is to make it as easy as possible to upgrade. Remove all barriers to your customers doing so. Make it quick. Make it reliable. Make it so that it doesn't confuse them or remove things of value to them. If you can do all that and your customers truly trust you, then you can potentially require them to manually upgrade to the latest version to work through support issues.

If that still isn't good enough, then you have to figure out ways to support more versions more easily. This could be creating VM's for each supported version where the source code is already loaded and you're all ready to start debugging. Supporting an old version is just a matter of getting the right VM loaded.

Regardless of whether you deploy as a hosted service and/or a customer installed product, you still potentially run into another issue. What if releasing small things all the time doesn't give you the splash that a big release might have? Well, in that case, you could differentiate between a release and a launch. You could go to market with a big splash even though it represents the work over the past few releases.

The bottom line is that frequent releases have a lot of advantages. They give you more feedback. They limit how far you can go down a bad path. They give customers what they want / need more quickly. They make upgrades easier (less change means less to debug if something goes wrong). Marketing, Engineering and Support have to work together to decide what the right frequency is for your situation.