What makes you think it is updating based on last-write-time?
In my testing, when I deploy a package to an Azure Web Site containing files where nothing has changed except the timestamp, I see lots of entries in the log similar to: Attribute 'lastWriteTime' equality changed to True when comparing filePath (octowebapptest\PostDeploy.ps1) to C:\Octopus\Work\20150928023413-4\PostDeploy.ps1 because of rule IgnoreFileLastWriteTime
And at the end: Successfully deployed to Azure. 0 objects added. 0 objects updated. 0 objects deleted.
This indicates to me that it is ignoring the the file timestamp.
And if I then modify one of the files, I see: Source filePath (C:\Octopus\Work\20150928030636-10\Web.config) does not match destination (octowebapptest\Web.config) differing in attributes (size['314','315'],lastWriteTime['09/28/2015 03:06:43','09/17/2015 12:18:30']). Update pending.
And at the end: Successfully deployed to Azure. 0 objects added. 1 objects updated. 0 objects deleted.
As you probably saw from the Calamari code, we rely on Microsoft Web Deploy for the synchronization implementation.
I would like to chime in that it’s still grudgingly slow. It’s possible that this is entirely a Web Deploy issue, or an Azure issue, but it’s spending minutes trying to compare these write times. Is there any optimization that can be done? It seems to just sequentially go through each file and check with the server if that file is touched, rather than uploading a large bulk of file information to compare on the server side and return back.
We are playing around with an idea to add a variable to the project that allows you to instead of sync the files as it currently does, just purge and install.
We think in these cases it will be the best solution for a large amount of files as the webdeploy sync plus Azure is slow.
Would definitely like the option to overwrite everything when deploying a web app to Azure. However do have some additional observations:
This happens to us on only one of our deployment types where we are deploying to a deployment slot that has previously been swapped with another slot. When we deploy to a slot that never gets swapped the deployments are quicker and rarely fail…
Sometimes the deployments never succeed, sometimes they take forever
Restarting the slot web apps (the one we’re trying to deploy to and the one we swap with), and cancelling the hanging release alleviates the problem for a day or two
Is it not possible to have an Octopus tentacle-like agent running as an azure plufg in or something similar so the deployment is not happening over the wire?
So we investigated everything we could around what WebDeploy has available and there is no way for us to avoid the check-sum processing during sync. So we determined way to best use Octopus to speed up these deployments was to provide some documentation on using Deployment Slots to implement Blue-Green deployments. As most of you have noted deploying the first time is really fast, this mimics that each time.
I just tried this recommendation. It does solve the part of not having to check for modified files, but it’s still slow due to having to upload a lot of unnecessary files that did not change. In my case the site is 200MB and that takes a lot of time to upload via web deploy. Based on internet speed tests it should take about 2 minutes to upload this with our uplink, so there is clearly some overhead or reduction towards Azure web deploy even though it is located in our region.
With checksum/last modified checking it took in the range of 3-6 minutes. When recreating deployment slot first it now takes 4 minutes on each of the first two attempts. I’ll keep running with this configuration to monitor over some time, but I’m unfortunately not seeing an improvement with this method.
I just realized you lose any changes you have made to that deployment slot, since you are effectively deleting it and recreating it. Obvious in hindsight, but I lost all my custom domain and application settings that you may have to re-add as part of the automation script if you go this route. I’ve reverted back for now as this method was not an improvement for our project.
We tried this solution aswell and it increased the deploy time with about 2 minutes, We are running a nodeJS project and have around 8000 files that needs to be added, Is there any other way to solve this?
I’m trying to find a place to discuss Web Deploy improvements if that is the core of the slow timestamp comparison in Octopus, but I can’t find it on github or Microsoft Connect or anywhere else. Any ideas?
I need to bump this. We are consistently having trouble deploying our web app, and typically have to Try Again 2-3 times or more. A successful deployment takes about 4-6 minutes, and it hangs forever on failed attempts.
I can provide logs and create a new thread if necessary, just tell me what to do. The logs in the admin panel just seems hang on an arbitrary place in the timestamp checking. This is a 200+ MB deployment so this checking takes around 2-3 minutes alone. I suspect there is a deadlock or timeout issue regarding this in Octopus Deploy, instead of in Web Deploy. I haven’t tried Web Deploy much lately so that is another path we could investigate if it helps you.
For us deleting and recreating a slot resolved the issue. It’s slow because webdeploy compares file for changes one at a time. Without any files to compare it’s quick and it’s just writing new files to disk.