Safely Deploying Changes to Production Servers

When you deploy incremental changes on a production server, which is running and live all the time, you sometimes see error messages like “Compiler Error Message: The Type ‘XXX’ exists in both…”. Sometimes you find Application_Start event not firing although you shipped a new class, DLL or web.config. Sometimes, you find static variables not getting initialized and so on. There are so many weird things happening on web servers when you incrementally deploy changes to the server and the server has been up and running for several weeks. So, I came up with fool proof house keeping steps that we always do whenever we deploy some incremental change to our websites. These steps ensure that the web sites are properly recycled, caches are cleared, all the data stored at Application level is initialized.

First of all, you should have multiple web servers behind a load balancer. This way, you can take one server out of the production traffic, do your deployment and house keeping tasks like restarting IIS, and then put it back. Then you can do it for the second server and so on. This ensures there’s no outage for customer. If you can do it reasonably fast, hopefully customers won’t notice the discrepancy between the servers, some having new code and some having old code. You should only do this when your changes aren’t drastic. For example, you aren’t delivering a complete revamped UI. In that case, some users hitting server1 with latest UI will suddenly get a completely different experience and then on next page refresh, they might hit server2 with old code and get a totally different experience. This works for incremental non-dramatic changes only.

During deployment, you should follow these steps:

• Take server X out of load balancer so that it does not get any traffic.
• Stop all your .NET Windows services on the server.
• Stop IIS.
• Delete the Temporary ASP.NET folders of all .NET versions in case you have multiple .NET versions running. You can follow this link.
• Deploy the changes.
• Flush any distributed cache you have, for example, Velocity or Memcached.
• Start IIS.
• Start your .NET Windows services on the server.
• Warm up all websites by hitting major URLs on the websites. You should have some automated script to do this. You can use tinyget to hit some major URLs, especially pages that take a lot of time to compile. Read my post on keeping websites warm with zero coding.
• Put server X back to load balancer so that it starts receiving traffic.

That’s it. It should give you a clean deployment and prevent unexpected errors. You should print these steps and hang them on the desk of your deployment guys so that they never forget during deployment pressure.

Doing all these steps manually is risky. Under deployment time pressure, your production guys can make mistakes and screw up a server for good. So, I always prefer having a batch file that takes a server out and makes it ready for deploying code and then after the deployment is done, use another batch file to put the server back into load balancer traffic rotation after the server is warmed up.

Generally, load balancers are configured to hit some page on your website and keep the server alive if that page returns a HTTP 200. If not, it assumes the server is dead and takes it out of rotation. For example, say you have an alive.txt file on your website which is what load balancer is keeping an eye on. If it’s gone, the server is put out of the rotation. In that case, you can create some batch files that will take the server out, wait for couple of seconds to ensure the in-flight request is complete and then stop IIS, delete temporary ASP.NET files and make server ready to deploy stuff. Something like this:

serverout.bat
=====================
Ren alive.txt dead.txt
typeperf "\ASP.NET Applications(__Total__)\Requests Executing" -sc 30
iisreset /stop
rmdir /q /s "C:\WINDOWS\Microsoft.NET\Framework64\v1.1.4322\Temporary ASP.NET Files"
rmdir /q /s "C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files"
md "C:\WINDOWS\Microsoft.NET\Framework64\v1.1.4322\Temporary ASP.NET Files"
md "C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files"
xcacls "C:\WINDOWS\Microsoft.NET\Framework64\v1.1.4322\Temporary ASP.NET Files" 
/E /G MYMACHINE\IIS_WPG:F /Q
xcacls "C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files" 
/E /G MYMACHINE\IIS_WPG:F /Q

Similarly, you should have a batch file that starts IIS, warms up some pages, and then puts the server back into load balancer.

serverin.bat
============
SET TINYGET=C:\Program Files (x86)\IIS Resources\TinyGet\tinyget.exe
iisreset /start"%TINYGET%" -srv:localhost -uri:http://localhost/ -status:200
ren dead.txt alive.txt
typeperf "\ASP.NET Applications(__Total__)\Requests Executing" -sc 30

Always try to automate these kind of admin chores. It’s difficult to do it right all the time manually under deployment pressure.