简体   繁体   中英

How to manage gradual deployment of a web app

I am developing a web app and want to be able to stagger the deployment of new builds and versions across our users. For example...

  • Deploy new version of app and migrate a couple of test accounts to it for testing
  • When testing is happy, move say 5% of customers to the new version and monitor support problems and server load problems with those customers.
  • if it is still going ok, gradually move more and more customers over to the new version until everyone is updated.

Fogbugz and Kiln from FogCreek are using a deployment system like this. You can read about it here...

The problem I am trying to solve at the moment is that different accounts on the system can be using different versions of the code .

What is a good way of managing and controlling this? Can Apache do some of the heavy lifting here? I want to avoid too much overhead, or weird loader scripts to work out where to send the request. How do web apps like Fogbugz on Demand deal with the problem? Is there a recognised design pattern for this?

The users are identified via a domain name (eg user1.example.com, user-bob.example.com, etc).

There are easily hundreds of ways to accomplish this; so let's think at a high level without talking specifics of the architecture:

  • Large public sites like Yahoo and MSN handle design changes with random samples and set cookies with long timeouts to identify who should be receiving the new design.
  • For paid upgrades and beta invites you should be able to identify and tag which customer accounts will receive the new 'design' or feature set upon their login. For instance, the new updates to Digg v4 were for logged-in and opted-in customers only. Facebook had a similar rollout across their system with the new profile pages.
  • You may decide to pay for beta testers. You can easily use Amazon's Mechanical Turk or sites like custfeedback.com

The specifics will be up to you and your architecture. Hopefully you've written your software with this functionality in mind; and hopefully you've provided easy ways to provide both application and database upgrades easily at deploy time. Magento (an open-source e-commerce platform) handles this very well. Each module is built in a form of a plugin and each of its components keep record of their own version. Database upgrades are performed on the fly with install and upgrade scripts based on the new/future version retained in configuration files.

You may choose to move your beta testers to a new domain or database that has more detailed logging and realtime analysis than your production machine. This was the method mentioned in the Kiln blog post - they referenced the site http://martinfowler.com/bliki/BlueGreenDeployment.html - eventually, however you accomplish the segregation of your accounts and traffic, you eventually have to consolidate. You'll need to perform your migration in a maintenance window most likely and get everyone up to the same version.

Best of luck!

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM