Versioning and client upgrade strategy for web applications

upgradeversioningweb-applications

I'm writing a web app and am wondering about future upgrades and how upgrading the webapp will affect the user experience.

In particular, I was wondering how a company like Google approaches this problem. For example, I have seen several examples where a particular google app will ask the user if they want to upgrade to 'the new google docs', or similar. This is the experience I would like to provide, but I'm not sure how to go about it. If it matter, I'm writing an app that uses backbone.js and has a heavy JS client side component. I have seen several discussions talking about versioning the REST component or the WebServices component, but none that discuss the actual client-side code or backend components (of course, the backend may not matter much if it is all behind a versioned webservice)

I'm interested in how they achieve this, from an application standpoint and from a (presumably) backend DB standpoint.

So it seems like there are several issues.

  • Where in the web root do the versioned applications live?

  • How do you serve multiple versions to different users?

  • How do you version the backend datastore?

  • Since I'm using backbone, I am particularly interested in to design the router for this type of app. If the various versions live in a subdir, how do I create a proper router?

There are probably some other considerations as well. Any advice would be welcome.

Best Answer

Using feature flags could help. Basically a feature flag tells the system whether a user should see a given piece of functionality. For example, if you just added a user settings option then you could wrap that with a feature flag to control who sees the feature. Some of the criteria a feature flag can consider include:

  • Global setting (allow everybody or nobody)
  • Specific users (allow specific beta users)
  • Random users (allow a percentage of users, e.g. for A/B testing)
  • Timestamp (allow use after the launch date or during a specific time of day)

Feature flags can compliment use of load balancing and staggered deployments. For example, if you want to go live with a feature at a precise time, you'd do a staggered deployment and then flip the switch. More generally, this allows you to change the behavior of the running site without being as dependent on how deployments are timed.

Related Topic