On a site I’m working with, we’ve got two classes of changes they can ask for. On one hand, they’ve got stuff that I’d have to rebuild and redeploy. They count these as “downtime” changes, because we display a nice little splash screen and we test the site thoroughly when we come back up.
On the other hand, they ask us to do a number of text changes, turning features on and off, etc., which we’ve isolated to the web.config. We offer to do these either inside or outside of deployment windows – we just edit the file, check that the change is right, and go back to work.
But one of the smart guys on the client side pointed out that editing web.config recycles the app pool, and that’s downtime right there. I’d never noticed, but I suppose that’s right – while the app pool is unavailable, the app is “down”.
But for how long? I’m not asking you to sort through the client’s level of comfort with downtime intervals, but is this a common perspective? Or should we just not worry that web.config editing is accompanied by a second or two of application downtime?
IIS recycles the app pool by itself normally, and if those recycles don’t cause you concern, this once shouldn’t either.
The user shouldn’t receive any sort of “service unavailable” errors, afaik.