Web应用程序部署到有限的用户群

Question

I'm trying to determine the best way of deploying new versions of an established web application. In the past, I've done it a couple different ways but this time we're looking to do something a little different/better.

We're using development/staging/production servers. After the development is done and the basic functionality is tested, we run the development code with an upgraded production database on the staging server. If our internal QA doesn't find problems in the staging environment, we make those changes live.

That last step has been done in the following two ways:

1. Upgrade the code and the database schema at a time of low usage, do a bit of testing to make sure the upgrades went OK, then cross fingers and hope the users don't find some bug that QA missed, always ready to put out fires or revert to the previous version in case of major failure.

2. Create the new version of the application at a different URL. Copy the production database to a new version, empty it, then copy over data for selected users and have them use the new URL. I.e., they would access the application from www2.example.com instead of www.example.com. Slowly move every user to the new version then switch the urls back.

This time I'm looking at doing something like a combination of the two methods. Basically, I'm thinking of moving a small number of users to the new service while keeping the same url.

Here's what I'm considering doing in the virtual host. Map.txt would be generated/updated when the new users are moved over. (I looked at using the prg rewrite map but am afraid of apache hanging waiting for the script.)

<VirtualHost *:80>
ServerAdmin [e-mail]
DocumentRoot /web/www.example.com
ServerName www.example.com

RewriteEngine  on

RewriteMap deploymentmap txt:/web/map.txt

RewriteRule ^/id/([0-9]+)/(.*)$ ${deploymentmap:$1}/id/$1/$2

</VirtualHost>

map.txt:

10001 /web/www2.example.com/
10002 /web/www2.example.com/
10003 /web/www2.example.com/
10004 /web/www2.example.com/
10005 /web/www2.example.com/

Are there any obvious flaws in this deployment strategy? Am I missing some simple and effective, less painful, upgrade method?

Thanks in advance for any assistance.

-Paul

Answer 1

Nobody ever answered, so I'll answer myself for posterity. :-)

This method works very well for a staged deployment of a new codebase over an old codebase. In our particular situation, we did the rollout using a method similar to the above. Initially, all users started with the old system and the rewrite map file was about 800K in size. The server served more than 100K pages with no noticeable difference in speed due to the new rewrite directives.

I was surprised that Apache didn't have to be restarted after making changes to remove entries from the file (the documentation implies this file is read only at startup). Apache picked up changes to the map right away so it must look at it on every request, or more likely check timestamps/checksums to see if it's different.

A similar technique could be used not only for deployment but for A/B testing especially in situations where the data structure isn't changing.