I've run into a couple scenarios recently where customers want to have access to multiple versions of a site at the same time.
Why multiple versions
The first scenario involved an analysis application where a bit of simulation code changed. In that case we were fairly sure that the customer would want to use the updated model, but we wanted to provide access to both versions so they could do some comparisons.
The second scenario involved an application that pulled data from a remote database, cleaned it up, and provided an interface for browsing the data. The format of the data in the remote database changed, but the customer wanted to be able to still connect and update from tables containing data in the old format as well as the new format.
For both of these situations, it would have been possible to edit the user interface and the backend code to allow access to both versions of the application at the same time, but this would have made for more confusing interfaces and a much more complex codebase.
Why subdomains
There are 2 main ways to handle serving 2 versions at the same time: 1) using different ports 2) using subdomains. Each method has its upsides and downsides.
If you serve off multiple ports, you first have to open another port in your firewall. For many applications (esp. those sitting in a customer testbed) this isn't a big deal. In my group's situation, we deploy into some pretty tightly monitored environments, and minimizing the number of open ports makes certification and approval a simpler process. Also, serving off of multiple ports makes just makes for less pretty urls. "simv2test.myapplication.com" is just cleaner and more self documenting than "myapplication.com:8080".
If you choose to work with subdomains, you'll need a wildcard DNS record to be able to grab all the traffic to your site. Some hosts and DNS services provide this automatically, and some make you pay more for that service. Also, if you're serving over SSL, you'll need a wildcard SSL certificate. This may also cost a bit more than a normal single domain certificate.
After considering both options, we decided subdomains made more sense in each of the scenarios described above.
How
First consider your data. In both of the situations described above we were serving up 2 different versions of the code and the data. We handled this by copying our database into a new database, and pointing the new fork of the application at this new database.
In mysql the command was as simple as this (after creating the "appname_2013" database):
sudo mysqldump appname | sudo mysql appname_simv2test
Mongo has a command specifically for this, which can be evoked from the mongo shell.
Next, setup the application code. The code for one of the projects was being served from "/var/www/deploy/appname/", so I copied the new version of the code to "/var/www/deploy/appname_simv2test". Make sure to make the necessary permission changed to the files and directories. I found that writing a fabric task to deploy each version of the application made this much easier.
Finally, setup your apache configuration to serve up each version of the application at the appropriate subdomains. Something like the following should work ok.
You probably don't want to do this with too many subdomains on one server, because each subdomain is basically doubling the amount of resources running on your computers (2x number of application threads, 2x number of database tables).
But for a simple temporary solution, that should do it.
BONUS
Here's a version that deploys over ports instead of subdomains. One of the ports is served over https (port 80 redirected to 443), and the other is just over http on port 8080.
No comments:
Post a Comment