During a deployment is it important to stop BOTH IIS site AND App pool a best practice for the deploy or does the deployment cause those to be bounced anyways?
It is important to understand what exactly is getting deployed in the first place. When you build a .NET application you are building the .dlls as an interpreted language, or IL. The first person who hits the ASP.NET website after a deployment causes Windows to compile that into native assembly language using the just in time, or JIT, compiler.
Several things trigger the JIT compiler to run. A change to the .dll, a change to a web.config file, an app pool recycle, an IIS start and stop.
What Octopus does out of the box is deploy to a new folder then it changes IIS to point to that new folder. That makes IIS think the .dlls changed which invokes the JIT compiler. This is not true for custom install directories. For example, always install MyApp to D:\Websites\MyApp
If you deploy a series of changes to the same folder (D:\Websites\MyApp) in a high traffic site you are running the risk someone hitting IIS after the some of the .dlls have deployed, which trigger a JIT compile, but before the rest of the site has finished. In the past, prior to Octopus Deploy, I had a script which added a space at the end of the web.config file which forced the recompile.
Our recommendation is (in order of precedence):
- Use the default behavior of Octopus, have it deploy to a new folder, and once it is done, change IIS to point to that new folder
- Use a custom install directory, but have it be unique per install (D:\Websites\MyApp\v1.1.3.2). The downside to this is we don’t run retention policies on custom install directory. Octopus will point IIS to that new folder once it is done.
- Add an app_offline.htm file to stop all traffic from being processed, once the deployment is complete, remove the app_offline.htm file.
- Stop the App Pool, deploy, start the App Pool