ASP.NET - Basic checklist for putting a site into production

Question

I'm building a static ASP.NET site (using Masterpages and a few forms) and I'm about to release it onto my production server.

I know about changing <compilation debug="true"> to false, but I'm wondering what other things I can do to obtain the highest speed possible. There is no data access in the site, it's all static content.

Does anyone have a checklist they run through or know of a good resource for setting up sites in a production environment, with a focus on performance?

Checklist so far (Feel free to edit this yourself with any worth additions)

1. Make sure <compilation debug="false" /> is actually set to false in Web.Config
2. Make sure <trace enabled="false" /> is actually set to false in Web.Config
3. Set necessary read/write/modify folder permissions for site
4. Enable GZIP in IIS (reduces size of pages/css/javascript dramatically)
5. Have you considered OutputCaching for any pages / controls?
6. Consider setting up Web Tests (Eg WatiN for .NET) to make sure functionality on your site is still working ok
7. Make sure it isn't Friday afternoon!

Answer 1

Review your web.config

Check debug (web.config / *.svc), tracing, ...

Update debug to production values:

• email addresses
• (web)service addresses
• location log files

quick search: link

Answer 2

Also, don't forget to check the gzip settings in IIS. Compressing output will make things travel across the wire much faster.

Answer 3

if its all static content, you'll want to use aggressive Output Caching

Answer 4

If you're writing any log or output files, make sure the proper folder permissions are setup in the production environment. Typically debug/test environments are much more lax on file read/write permissions than production.

Answer 5

If your site use a database and only presenting information, make the database read-only. That takes away all locking handling and speeds upp the access a great deal.

If you have a back-end that updates the data, make it a separate database and have sheduled periods that update the readonly database once a day or what is needed for that application.

If you just present news and other small things on a company web-site that not change so often then this solution is probably for you. Even if its a site with gigabytes of data.. The key word is, how often does we update the data?

From what I see in daily business,noone really thinks about this solution because everything has to be "real time", but there are plenty of cases where this would be a perfect solution.

Answer 6

Don't deploy on Friday afternoons! This is guaranteed to mess up your head for the weekend.

Shawn, www.codersbarn.com

Answer 7

You should have some sort of test to verify various functions of your site, and the permissions. For instance, once you publish. Walk through a checklist, can I access x if I don't have permission? Does x,y,z work on the application? I do this after every publish because small changes can have a big impact.

Answer 8

There is actually a very good checklist on how to perform a security deployment review provided on MSDN.

Answer 9

You should read this:
http://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site

It's currently the 9th highest voted question on SO and in the top 3 most favorited. The caveat is that it's platform agnostic, so it's missing some ASP.Net-specific items.

Answer 10

Thoroughly test the site outside of your corporate firewall / proxy after clearing your browser cache. This will help to ensure that all resources are publicly accessible (and are not on a local server or cached). For instance, you might find that you have used absolute URLs to include, say, JavaScript or CSS files. These work fine in your development environment, but as soon as the site goes live they are inaccessible. Or you have a CSS file in your cache that has subsequently been deleted, but you don't notice.

Ensure that any products / applications you use that have keys that are tied to a domain will work on your live site. This includes things like Google Map keys or commercial 3rd party applications. It also includes automatically generated hyper-links sent out in, say, emails. You wouldn't want a user registration to have a link back to http://localhost/comfirm.aspx or the like, would you?