Asp.net deployment. How to push to production server.

Question

Imagine that we have a sophisticated asp.net solution: MSSQL + ASP.NET MVC + ASP.NET Web Forms + WCF Service hosted in IIS.

Once a week the solution must be deployed to a single production server transparently for the users. The deployment can include changes in database scheme, minor IIS reconfiguration, replacement of files. The deployment consumes time and may affect uptime.

How can I deploy without the interruption of users or minimize the downtime? What are the techniques and best practices?

(e.g. switch staging/production environments)

Answer 1

If your overriding concern is uptime, you could look at load balanced servers for the site - one can be taken down, updated and then brought back up while the other is then updated. You'd need to look at how you manage your sessions in this scenario, e.g. use sql server or state server mechanisms.

Answer 2

• Look at the times when the least number of people are using the system and aim to get the updates done then.
• If you are just applying updates to the DB server then you only really need to worry about backing it up encase something fails, no need to take it off-line.
• You should be able to upload the new pages without any interruption to the users.
• Automate it as much as possible to reduce the risk of human error, I would recommend Wix for this as it can

Answer 3

I cannot offer a complete solution but a few points that "worked for me":

• Split your DB upgrades into (a) changes that are backwards compatible and (b) breaking changes. That way, you can run part (a) (add fields, add tables, add indexes, ...) while the old version of the software is still running. For part (b) (change field types, convert data, ...), I don't think it is possible to avoid downtime. Try to make most DB changes non-breaking.

• Announce the downtime so that your users can adapt to it. While you are upgrading, use the app_offline.htm feature to make sure your users see a nice error message explaining the situation. It also ensures that your application is reloaded. An in-place, no-downtime upgrade of a web application without reloading (i.e. "just replace the files") can cause strange errors.

• Test the upgrade: Make a copy of the production system (software plus database), which should be doable while the system is running. Perform the upgrade on a test system. If there are problems during the upgrade: fix the problems, improve your upgrade procedure and repeat.