Versioning and client upgrade strategy for web applications

Question

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.

Answer 1

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.

Answer 2

It is not possible because of security reasons to ask the web-client-user if he wishes to upgrade the web-server-app. A web app that has write access into its own program folder will make a lot of hackers happy.

On an android/iphone app you have a mobile-device-local-installed-app that can be updated locally if the user allows it.

the example with upgrade to 'the new google docs' is not software update on the server but one of two features that are both implemented on the server at the same time and the "upgrade-switch" just asks which of the two features to use.

Answer 3

If you wish to be able to stagger the upgrading of users you need (in the abstract):

• multiple webservers behind a load balancer so you can have two (or more) versions of the web site live at any one time.
• a common database/login system so that you have one point of entry and a way of recording which version of the site each user normally accesses.

Thus when a user logs in the database will indicate which version of the site is required and then the load balancer will direct the user at the appropriate version. Clearly it's a lot more complicated than that, but that's the basic principle.

You'd normally only have two versions, but you could also include a third low bandwidth version as a fallback and/or mobile version of the site using the same technology.