Hello all. I just installed OD. Deployments to my IIS websites are running well. Of the 5 deployments I’ve done thus far, 1 or 2 times I noticed my site returning a 503 Service Unavailable error for about 30-45 seconds while the files were being copied to the actual website folder. After that, everything was fine.
I suspect it’s related to the site restarting while DLLs were being copied to the BIN folder and other sensitive files like the web.config file getting copied over. Not sure if it matters, but I’m using the “Deploy a Package” option rather than the “Deploy to IIS” option because my site is already fully configured in IIS and I didn’t want to deal with bindings getting overwritten, and any issues with which SSL cert gets picked, etc.
QUESTION #1 - do you have any suggestions on how to ensure there are no 503 Service Unavailable errors while the site is being updated? I don’t mind if the first couple of requests to the site after the deployment take a while to complete while the site is restarting which always has happened when updating the BIN folder manually… it’s the 503 Service Unavailable errors which are a bit disconcerting.
QUESTION #2 - it appears that all the files from the package get copied to the website folder. I was curious if there’s an option to only have the updated files deployed? I’m wondering if that could help with this issue, plus it seems slightly more efficient for the actual update process. i.e. if I have 500 files and only 1 file has changed, updating just that 1 file would have less of an impact on the website.
Website is on Windows 2008 R2 IIS 7.5
Octopus Deploy 3.16.0
Cheers,
Ben
Hi Ben,
Thanks for getting in touch!
We believe the the 503 errors are being caused as Octopus and IIS aren’t aware of each other and so Octopus is overwriting files that are in use causing IIS to error. One suggestion that we have is to have blue/green production deployment folders that you can deploy to.
What I mean by that is you would have two directories that you can deploy to, lets say c:\inetpub\www_1\ and c:\inetpub\www_2. If the site is currently using the “www_1” folder then you would deploy from Octopus to “www_2” then update IIS to point the virtual directory to www_2 once the deployment finished. Then, for the next deployment you would do the opposite (deploy to www_1, then update IIS to point back to www_1).
As for your second question, Octopus currently uses Delta compression for the package transfer itself (so from your Octopus Server to the Octopus Tentacle). With the “Deploy a Package” step, once the package is transferred it is then extracted to a working directory then copied to the final destination. As Octopus doesn’t monitor the final destination directory at all we, by design, will re-deploy all files as we don’t know if anything has changed since the last deployment.
If this is something that you would like us to pursue please log a uservoice requesting the feature. We actively monitor these requests and, if it receives enough community support, we will investigate implementation. My first pass at this I feel we would be trading a saving in file/copy time for extra overhead in CPU time as we would have to compare each file before starting the transfer. This might still be worthwhile, but would have to be investigated.
Please let me know if there is anything else I can assist with,
Regards
Alex
Hi Alex, thanks so much for the information and ideas here.
The blue/green deployment strategy sounds very promising - I’ve not heard of that before. I found a couple of articles on this on the Octopus site! (links below) We may experiment with this to see how well it works.
The Octopus Delta compression works very well. I noticed on one deployment it only needed to send 3% of the package - a 97% savings 
Our previous method of deployment was using a Beyond Compare script to compare the deployment folder to the target website folder and copied just the changed files. It’s true the comparsion itself incurs CPU and I/O, but then the actual deployment to the website folder has minimal impact which is the main upside. It looks like we could maybe even tie that script in with Octopus by using the “Transfer Package” Octopus step to just transfer the package to the tentacle, and then run that Beyond Compare script to compare the package contents to the website folder and only copy the changed files. Just another idea we had. So a couple of different things we can try out. Thanks again for your input.
Regards,
Ben
https://octopus.com/docs/patterns/blue-green-deployments
https://octopus.com/docs/patterns/blue-green-deployments/blue-green-deployments-in-iis
https://kevinareed.com/2015/11/07/how-to-deploy-anything-in-iis-with-zero-downtime-on-a-single-server/
Hi Ben,
No problems! As I mentioned feel free to put in a Uservoice for delta only changes for output directories as it may indeed be something that is worthwhile, just not something that has bubbled up onto our radar as yet. Your workaround using a Beyond Compare script should work nicely in any case 
Please let me know if you have any other questions or if there is anything else we can assist with,
Regards
Alex