How can I update my site without forcing users to wait?

Question

Downtime is inconvenient for users and currently they have to wait any time a site's engine is being upgraded. Additionally, when using off-the-shelf scripts there's a risk that a setting change won't work as well as intended (even if they've been tested on a staging site).

How can I keep multiple versions of a site on a server and switch between them without causing any downtime (e.g. with a htaccess file)?

Answer 1

You can use virtual hosts in apache to have 2 versions of the code at 2 different urls. A commonly used example is:

test.example.com -> /var/www/version1.2

www.example.com -> /var/www/version1.1

both of which are on the same server, but perhaps only one is accessible to the world. Once you are satisfied that test.example.com is working, you can just change where they point to in your apache config and... presto. New site, new code. Assuming there were no database schema changes this should work. So after you make the change it will be:

test.example.com -> /var/www/newtestversion

www.example.com -> /var/www/version1.2

Here is an example apache config directive for a virtual host:

<VirtualHost *:80>

     ServerAdmin gabe@localhost

     DocumentRoot "/var/www/version1.1"

     ServerName test.example.com

</VirtualHost>

For more info on how to do this, see the apache virtual host documentation

I'm not sure how to do this in IIS, but I imagine there is also a way.

If something goes wrong, switch the virtual host back to the original, and your old site is back... no problems. You do have to restart apache for these changes to take effect, but that is generally a very fast thing to do.

Answer 2

Are you on a Linux/BSD machine? If so, you can easily use symbolic links to accomplish this goal.

Create Version 1 of the site here:

/var/www/www.example.org.v1

Create a symbolic link pointing to this directory

cd /var/www
ln -s www.example.com.v1 www.example.com

This should give you a directory listing (ls -la) that looks something like this:

lrwxr-xr-x   1 userid  users    18 Aug  3 03:35 www.example.com -> www.example.com.v1
drwxr-xr-x   2 userid  users   512 Aug  3 03:35 www.example.com.v1

Set your web server to use /var/www/www.example.com as its document root. You will never have to change this; all re-pointing will be done at the filesystem level.

Now, when you want to swap in Version 2 of the site all you have to do is place the new version in:

/var/www/www.example.org.v2

And update the symbolic link to point to this version:

ln -sfh www.example.com.v2 www.example.com

Which will leave your directory output looking like this:

lrwxr-xr-x   1 userid  users    18 Aug  3 03:43 www.example.com -> www.example.com.v2
drwxr-xr-x   2 userid  users   512 Aug  3 03:42 www.example.com.v1
drwxr-xr-x   2 userid  users   512 Aug  3 03:41 www.example.com.v2

As you can see, the www.example.com symbolic link is now pointing to Version 2 of your site. This is an atomic operation and should not cause any downtime related to files being unavailable.

Of course, there is still considerable complexity required in ensuring that database structures are updated, any static resources are available (and linked to the correct version), etc, but at least this takes care of making sure that all of the right resources for the new site are instantly available.

Windows Vista and Server 2008 also support symbolic links using the mklink command, though I don't have any direct experience with them.

Answer 3

In IIS you can set up a second virtual directory with your updates.

You then redirect all requests, or remap the bindings of the second site to your desired host name

Http Redirection in IIS 7: http://technet.microsoft.com/en-us/library/cc732930(WS.10).aspx

Answer 4

What I would suggest:

• Test locally on a development server before uploading any changes. Don't make the changes on a live server until you're reasonably sure it works on the test server.
• Perform maintenance at your least heavy traffic time. For most websites, this will be in the early morning hours on the weekends. If weekends aren't an option, then do it during your least-trafficked time during the week.
• Warn your users of scheduled maintenance ahead of time.