Scott,

Looking for best method and practices to upgrade live sites.

Can you enlighten us on the steps you follow to "dog food" new revs on dontnetnuke.com?

Reading your blog you identify the site to be down for a few minutes here and there.  Exactly how do you update the files and prevent access to  links during the process?  Have you ever had to back out an upgrade?  If so how?

Just looking for some best practice advise here.

1. The mere presence of a file called app_offline.htm in the approot prevents anyone accessing your site while you transfer files, prep your web.config, and otherwise get the site ready for the upgrade.
2. autoUpgrade = false in the web.config prevents anyone from kicking off the installation or upgrade from the root or any location other than ~/install/install/aspx. The purpose being that YOU will navigate there to initiate the process and others hitting other parts of your site will get a notifcation that  the site is temporarily unavailable until the process is complete.

Between the two, you can control the installation and show friendly notices to anyone accessing your site while it's in an inconsistent state.

In our case we maintain our own servers and so have access to the local machines and IIS.  We simply have a default site that will catch incoming requests when the main site is down.  You may have caught a page once in a while that says "System Maintenance"... etc.  When the site comes down, we perform a DB snapshot and a full folder backup (which is incremental for us, and so reasonably quick despite a large number of files).  Upgrade files are overlayed and the updated web.config added.  Then the site is brought up in a website which answers only on localhost... which is how we avoid public upgrade (if you did not have access to the box, you could also use a site which is limited access only to your remote IP, etc).  When the upgrade is complete, that site is shutdown and public site is restarted.

Scott Willhite, Co-Founder DNN