How to deploy an ASP.NET Application with zero downtime

Question

To deploy a new version of our website we do the following:

1. Zip up the new code, and upload it to the server.
2. On the live server, delete all the live code from the IIS website directory.
3. Extract the new code zipfile into the now empty IIS directory

This process is all scripted, and happens quite quickly, but there can still be a 10-20 second downtime when the old files are being deleted, and the new files being deployed.

Any suggestions on a 0 second downtime method?

Answer 1

The only zero downtime methods I can think of involve hosting on at least 2 servers.

Answer 2

You need 2 servers and a load balancer. Here's in steps:

1. Turn all traffic on Server 2
2. Deploy on Server 1
3. Test Server 1
4. Turn all traffic on Server 1
5. Deploy on Server 2
6. Test Server 2
7. Turn traffic on both servers

Thing is, even in this case you will still have application restarts and loss of sessions if you are using "sticky sessions". If you have database sessions or a state server, then everything should be fine.

Answer 3

The Microsoft Web Deployment Tool supports this to some degree:

Enables Windows Transactional File System (TxF) support. When TxF support is enabled, file operations are atomic; that is, they either succeed or fail completely. This ensures data integrity and prevents data or files from existing in a "half-way" or corrupted state. In MS Deploy, TxF is disabled by default.

It seems the transaction is for the entire sync. Also, TxF is a feature of Windows Server 2008, so this transaction feature will not work with earlier versions.

I believe it's possible to modify your script for 0-downtime using folders as versions and the IIS metabase:

• for an existing path/url:
  • path: \web\app\v2.0\
  • url: http://app
• Copy new (or modified) website to server under
  • \web\app\v2.1\
• Modify IIS metabase to change the website path
  • from \web\app\2.0\
  • to \web\app\v2.1\

This method offers the following benefits:

• In the event new version has a problem, you can easily rollback to v2.0
• To deploy to multiple physical or virtual servers, you could use your script for file deployment. Once all servers have the new version, you can simultaneously change all servers' metabases using the Microsoft Web Deployment Tool.

Answer 4

If you do something like what GT said(I can't add a comment), you might lose session which would give a perceived restart. If you store session not inproc, you might get away with it, just the first few requests might be slow.

Other than switch around the folders, you could have two DNS names, server1.website.com and server2.website.com . Then set them up as two different websites, when you go to roll a new version, have server1 redirect to the same box, but to the other host name. You would have the web site installed twice, and would also need to store session out of proc and check your cookies. That should work though in theory.

Answer 5

I would suggest keeping the old files there and simply overwriting them. That way the downtime is limited to single-file overwrite times and there is only ever one file missing at a time.

Not sure this helps in a "web application" though (i think you are saying that's what you're using), which is why we always use "web sites". Also with "web sites" deploying doesn't restart your site and drop all the user sessions.

Answer 6

I would refine George's answer a bit, as follows, for a single server:

1. Use a Web Deployment Project to pre-compile the site into a single DLL
2. Zip up the new site, and upload it to the server
3. Unzip it to a new folder located in a folder with the right permissions for the site, so the unzipped files inherit the permissions correctly (perhaps e:\web, with subfolders v20090901, v20090916, etc)
4. Use IIS Manager to change the name of folder containing the site
5. Keep the old folder around for a while, so you can fallback to it in the event of problems

Step 4 will cause the IIS worker process to recycle.

This is only zero downtime if you're not using InProc sessions; use SQL mode instead if you can (even better, avoid session state entirely).

Of course, it's a little more involved when there are multiple servers and/or database changes....

Answer 7

I went through this recently and the solution I came up with was to have two sites set up in IIS and to switch between them.

For my configuration, I had a web directory for each A and B site like this: c:\Intranet\Live A\Interface c:\Intranet\Live B\Interface

In IIS, I have two identical sites (same ports, authentication etc) each with their own application pool. One of the sites is running (A) and the other is stopped (B). the live one also has the live host header.

When it comes to deploy to live, I simply publish to the STOPPED site's location. Because I can access the B site using its port, I can pre-warm the site so the first user doesn't cause an application start. Then using a batch file I copy the live host header to B, stop A and start B.