Let's imagine you are building a Calculator application. You will allow customers to customize this Calculator with their own logos and CSS stylesheets. Customers will point their domains to your hosted Calculator and the application will serve up the correct theme for each customer. For example:
- www.AcmeCalculator.com will serve up the Calculator with the Acme logo, and a bland corporate style they created.
- www.HellzCalc.com will server up the Calculator with some Hell's Angels biker signs and a black, blood red theme they created.
You've pushed out Calculator 1.0 and everyone has written their styles to work on this version.
Next month you are ready to release Calculator 1.1 which added a new feature, let's say "Scientific Mode" which required you to add some new UI - HTML in this example - components. This means if you push out 1.1, you will break some of your customer's styles.
The best solution I've come up with is that you keep multiple versions of your application running. For example:
- www.AcmeCalculator.com resolves to your app server, which checks the version Acme is currently on, and forwards to www.AcmeCalculator.com/1.0
- www.HellzCalc.com resolves to your app server, which notices that they are running on the new 1.1 version since they went in an updated their CSS to work on the new version and clicked the "Finish Upgrade" button or whatever, so they get redirected to "www.HellzCalc.com/1.1
One problem with this system is that you'll inevitably have lazy customers who never invest in upgrading. You'd be running 200 versions concurently, trying to fix bugs in each of them, basically going insane.
One solution would be to use part of your monthly hosting fee to employ a "UI Migration Team" which would be a group of designers whose only jobs is to constantly take clients in the queue running the oldest versions and tweak their CSS and validate them to run on the newest version. This would allow you to support only X versions concurrently, where X is a function of how much money you invest in the UI Migration Team, adding resources to speed them up or slow them down.
The same idea would work with database changes: Calculator 1.0 and 1.1 runs on database 1.0, but Calculator 1.2 runs on database 1.1, etc. You could just add schemas with version names, and employ a similar "Data Migration Team" to move data from schema 1.0 to schema 1.1, finally deleting schema 1.0 when no (app) clients are left.
I'm sure this type of problem has come up before, and I'd like to see how other have solved it. Perhaps there is even a "best practices" for this.