How do you approach release management for a web app (SaaS)?

Question

What is the best approach to releasing a new version of a hosted web app, and how often do you typically release? Do you pick an arbitrary date, say every week, month, etc. to rollout an accumulated set of fixes (perhaps using an approach similar to Joel's approach to ship dates)? Waiting much longer than that seems to defeat part of the major advantage of a hosted app. On the other hand, you wouldn't want to constantly roll out new features that might confuse the user (i.e., if there was something different every time he/she logged in).

Until recently my experience has been primarily with installed server-based or desktop apps. I am curious to see what type of release management people use with a hosted app.

Answer 1

Release early and often is what I do, and what we do where we work. We also blog about our updates whenever we make them. It's probably easier for you if you roll all your updates into one update at a time (for QA, having to rollback, etc) as best as you can. From a user perspective I don't think there's any problem with lots of updates. As long as they're not bad updates. I think there is a problem if you wait for an entire year or six months, and roll all your updates into one big release. That's what killed a project I used to work on (a popular feedreader you've probably heard of). People thought we were dead, and perception became reality. We got abandoned. So I'm all for firehose release schedules.

Answer 2

Every two weeks should be enough, but this depends very much on your market.

Answer 3

Google's approach is probably the best for the end user, but it comes at the cost of complexity.

They roll out new versions (and sometimes just individual changes) on a pretty constant basis (as often as daily, depending on the project). But here's the kicker: only a small portion of users are given the new version.

Google have a large number of users for their big products, so it's practical to put in rules like "5% of users should see this feature".

They can then analyse the results and plan their next release, perhaps to another 15% of the user population.

Answer 4

As much as engineers want to define a routine to live by, it is really going to be driven by the business demands behind the system. It also really depends on the nature of the updates, etc...

Content and HTML updates should not be a big deal to push out. Application changes SHOULD be a big deal, and go through the established testing routines on a preview site prior to being pushed live.

One thing for sure is that you need to have a very "clean" way to deploy (and undeploy) changes. You also need an "easy" way to review and audit the changes before they go live.

Using a mix of "git" and "rsync" allows us total control over the process. All changes to our project are developed in a branch that was branched from the "Production" branch. Before any changes can go live, the "Production" branch must be fully merged in. The act of going live is simply merging the appropriate branch into "Production" and rsyncing it to the live servers. Git makes this really easy.

This ensures that the changes going live cannot possibly conflict with other changes in progress.

Since adopting this system, our deployment routine has dramatically increased in efficiency and clarity. And by the way, our deployments range from multiple times per day to once every several months. It all depends. I would prefer a 1-2 release per week cycle on an active project.