I'm looking for a way to make the site deployment without downtime as cheap as possible. So far, I deploy the site by clicking stop in the IIS manager, deleting the old site files, uploading the new compiled site files to the same folder and clicking start in the IIS. Unfortunately, this will cause a short outage when the page is unavailable between clicking stop and start. I found that if I click edit site in the IIS, I can change the "physical path". Is it safe to switch this path while the site is running? My idea is that I will have two separate folders and when I want to deploy new version, I copy the content of the page to the second folder, then I just switch the path. I tried it and it seems to work, but I want to make sure that this is safe and I also ran into a few problems.
Problems with this solution: If there are any processes running on the original site and I switch the path, the new version will not be deployed until the processes have been completed. I verified this by putting a log in the database at startup so I would know when a new version was launched. If I change the path and click stop and start right after, the new version deploys immediately, but for some reason this doesn't work if I just click restart (if a request comes in between clicking stop and start, it won't be served, so it's a problem). The site consists of two services and both of them have to be deployed around the same time, so I need to be sure when the deployment happened and I can't wait for the processes to be completed. In my tests, it looked like if I deploy the site like this (switch path, then click stop and start immediately), the old processes are still completed, but new requests are already directed to the new version of the app.
Can I rely on such behavior in every situation? (that the old processes will still be completed and old requests served) Is there a way to force the new version to be deployed immediately without clicking stop and start?
Thank you for the answers and for your time
