On my QA and production servers I have 1 background procecss (Windows service) running with 5 different IIS ASP.NET MVC applications.
I have a folder c:\app\ which contains a subfolder named by the build number (i.e. c:\app\1234)
I am using Bamboo for my CI which runs a script that performs an update from SVN, compiles my solutions, and runs tests.
Finally, the script will us MSDeploy to push out the new files (all the IIS apps as well as the windows service app) to the target servers into the director c:\app{revision-number}
Up to this point, everything is perfect and I cannot see any issues with this. My question is related to the following part of the deployment.
After all the files are deployed to the servers, the service is remotely shut down and the path is updated from C:\app{old-revision} to c:\app{new-revision}.
Using MSdeploy, we remotely run commands (appcmd) to reconfigure each of the IIS apps (in a specific order) to have their root's point to the c:\app{new-revision}\xyz.
Once the apps are deployed and paths are updated, we restart the background service. At this point, the entire application is running the updated version. All in all, this process is very quick and after the files are uploaded, it takes just seconds to reconfigure all the apps.
The nice thing is that I can also run a rollback script that will quickly reconfigure the apps to point back to an older revision if something should go wrong.
Specifically, my question has to do with changing the root path of IIS applications.
I know that this will cause the application to be restarted (maybe even the app pool to be recycled?). Our sessions are stored out-of-process so sessions are still maintained even though the app restarts.
Is there anything else I should be aware of that could go wrong with this approach?
