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

Answer 1

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 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

Using Microsoft.Web.Administration's ServerManager class you can develop your own deployment agent.

The trick is to change the PhysicalPath of the VirtualDirectory, which results in an online atomic switch between old and new web apps.

Be aware that this can result in old and new AppDomains executing in parallel!

The problem is how to synchronize changes to databases etc.

By polling for the existence of AppDomains with old or new PhysicalPaths it is possible to detect when the old AppDomain(s) have terminated, and if the new AppDomain(s) have started up.

To force an AppDomain to start you must make an HTTP request (IIS 7.5 supports Autostart feature)

Now you need a way to block requests for the new AppDomain. I use a named mutex - which is created and owned by the deployment agent, waited on by the Application_Start of the new web app, and then released by the deployment agent once the database updates have been made.

(I use a marker file in the web app to enable the mutex wait behaviour) Once the new web app is running I delete the marker file.

Answer 4

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 5

You can achieve zero downtime deployment on a single server by utilizing Application Request Routing in IIS as a software load balancer between two local IIS sites on different ports. This is known as a blue green deployment strategy where only one of the two sites is available in the load balancer at any given time. Deploy to the site that is "down", warm it up, and bring it into the load balancer (usually by passing a Application Request Routing health check), then take the original site that was up, out of the "pool" (again by making its health check fail).

A full tutorial can be found here.

Answer 6

OK so since everyone is downvoting the answer I wrote way back in 2008*...

I will tell you how we do it now in 2014. We no longer use Web Sites because we are using ASP.NET MVC now.

We certainly do not need a load balancer and two servers to do it, that's fine if you have 3 servers for every website you maintain but it's total overkill for most websites.

Also, we don't rely on the latest wizard from Microsoft - too slow, and too much hidden magic, and too prone to changing its name.

Here's how we do it:

1. We have a post build step that copies generated DLLs into a 'bin-pub' folder.

2. We use Beyond Compare (which is excellent**) to verify and sync changed files (over FTP because that is widely supported) up to the production server

3. We have a secure URL on the website containing a button which copies everything in 'bin-pub' to 'bin' (taking a backup first to enable quick rollback). At this point the app restarts itself. Then our ORM checks if there are any tables or columns that need to be added and creates them.

That is only milliseconds downtime. The app restart can take a second or two but during the restart requests are buffered so there is effectively zero downtime.

The whole deployment process takes anywhere from 5 seconds to 30 minutes, depending how many files are changed and how many changes to review.

This way you do not have to copy an entire website to a different directory but just the bin folder. You also have complete control over the process and know exactly what is changing.

**We always do a quick eyeball of the changes we are deploying - as a last minute double check, so we know what to test and if anything breaks we ready. We use Beyond Compare because it lets you easily diff files over FTP. I would never do this without BC, you have no idea what you are overwriting.

*Scroll to the bottom to see it :( BTW I would no longer recommend Web Sites because they are slower to build and can crash badly with half compiled temp files. We used them in the past because they allowed more agile file-by-file deployment. Very quick to fix a minor issue and you can see exactly what you are deploying (if using Beyond Compare of course - otherwise forget it).