My current deployment process works something like this;
1. Make a copy of production for historical purposes; zip it up, store it
in archives
2. Move the contents of production into an emergency restore directory
(uncompressed)
3. Deploy the appropriate files from TEST to PROD (i.e. no .CS files, no
_temp dirs, etc).
4. Overlay PROD-specific files, such as a Web.config that has PROD database
settings and so on
For the same reasons as you, I've been considering a temporary "Web site is
being updated." page, but because the dir is temporarily empty, I'm not fond
of the temporary page idea or Web.config adjustments.
The direction I'm headed is to programmatically modify the website
configuration in IIS to point to a different directory--one that contains a
mini placeholder website, all pure HTML.
My deployments are done using an in-house tool, so the idea would be to
select the project, deploy to TEST, test it thoroughly, deploy to PROD,
which automatically takes PROD "offline". Once I've verified PROD, I click
the Online button to make access available again.
I haven't gone far down that route, or verified that I can make these
changes to IIS from another machine on the same network, but my initial
research was promising regarding Server2003 so you might consider the same
approach.
The second approach I'm considering is to manage production sites using
versioned directories, e.g.;
c:\inetpub\wwwroot\websitedir\1.0.0.38
c:\inetpub\wwwroot\websitedir\1.0.1.21
With a tool (or some tightly managed procedures), you can extract the
assembly version during deployment and make that its directory name. Then
once you've verified the site is working, "click" you programmatically
update IIS to point the site at the new version directory.
The advantage is that the current site is running until the moment you click
"approved", so there's virtually no downtime; however this clearly presents
issues if you've modified a shared resource, such as a database schema. In
that case PROD(current) would break the moment you make the schema change,
and PROD(new) won't work until you make the schema change.
The placeholder site seems to be the best lowest-common-denominator
solution.
Have fun, and please keep me posted on the direction you take.
/// M
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:ep**************@TK2MSFTNGP15.phx.gbl...
I don't know if there's a penalty but perhaps,
a simple solution -if you use Forms Authentication-
is to rename login.aspx to login.aspx.bak, and setup
a customerrors page which explains that the site will
be back shortly.
When you're done, rename login.aspx.bak back to
login.aspx, and restore your usual customerrors page.
If it's an open site ( no authentication ), you could simply
write an httpHandler which redirects all users to another
Application where you explain what's going on.
You could also do that if you use
Forms or Windows authetication.
Juan T. Llibre
ASP.NET MVP
===========
"Jeremy S." <A@B.COM> wrote in message
news:uF**************@TK2MSFTNGP09.phx.gbl... Sounds good. Is there any meaningful/noticeable performance penalty for
having this HttpModule?
"Jens Hofmann" <sp**@dev-com.de> wrote in message
news:uE**************@tk2msftngp13.phx.gbl... Have a look at HttpModule. You can develope one which
checks a DateRange defined in Web.Config and a URL
defined in Web.Config and if a request comes in between
the DateRange you redirect the request to the defined page.
This is normal Maintenance-Mechanism.
Cu Jens
"Jeremy S." <A@B.COM> schrieb im Newsbeitrag
news:OW*************@TK2MSFTNGP12.phx.gbl...
Sorry if this is too far OT - I posted this in the IIS group and got
no response - so here goes:
What would be a good or recommended way to make a Web site in IIS6
inaccessible to users on the Internet. My situation is that I will
periodically update a ASP.NET Web application. While I am making the
update (which will take only a couple of minutes, max) and
subsequently checking that everything works as planned after the update (which may
take 5-20 minutes), I don't want any visitors to access *any* pages in
the site. Rather, they should get some page that tells them what to
expect (e.g., "please try again later" or whatever).
Thanks!
