I have a constant battle trying to get Web Apps up to Azure.
It gets down to the part where it says:
Deploying to Azure WebApp ‘mywebsite(slotname)’ using subscription-id ‘xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx’'
And it just sits here forever…
The deployment says “This task started 56 minutes ago and should have finished 51 minutes ago”.
Why does it not just timeout and retry?
My company is on a 100MB business fibre connection that is not busy so I don’t know what to make of this.
Just to add, if I cancel and retry a few times it eventually works
Have you seen this post?: http://help.octopusdeploy.com/discussions/problems/44216-frequently-hang-on-deploying-large-azure-web-app
We had a lot of issues with this before the timestamp option was there. We got around it by making a fresh deployment slot and switching after the deployment task finished: http://docs.octopusdeploy.com/display/OD/Using+Deployment+Slots+with+Azure+Web+Apps
Thanks for getting in touch. What Mike mentioned is correct, you should have success using Timestamp instead of Checksum, or by deploying to a new Slot and switching.
I’m writing a blog post today as another way to get the word out about this.
Hope that helps!
Thanks Mike, I will try the timestamp approach. I am not sure how deploying to a new slot will help. Currently, this is happening on both the slots and the primary web app.
From what I understand the issue is with WebDeploy having to traverse every file and folder on existing deployments to calculate the checksums. From my experience anything more than a few hundred files has a high chance of failing.
By making a new Staging slot WebDeploy only needs to check the checksum of the default Azure HTML file.
What Mike said is right, but to be more precise, you will get this benefit when deploying to an empty slot.
Hope that helps!
Thanks for getting back to me with that information. From what I’ve seen also, a slow or lossy network connection can cause the same symptoms on very small applications.
Hopefully now we’ve got the right knobs/controls to tune deployments to be as reliable as we can make them.
Please do keep in touch if there’s anything else we can do to help.
Thanks for the help guys, I have changed to timestamp and it seems to be working.