New Web Deploy feature in Windows Azure SDK refresh–when to use

Anders Hauge has published a great article on the new Web Deploy feature here: blogs.msdn.com/b/cloud/archive/2011/04/19/enabling-web-deploy-for-windows-azure-web-roles-with-visual-studio.aspx and describes it as a great Test & Dev feature (which it absolutely is – I positively love this feature, it cuts down tremendously on “trial and error” cycles – congratulations to the SDK team for implementing this!).

What the article does not go into any detail on is what the limitations of this type of deployment lie. Not that those would be reducing the value of this new feature, but it’s important to note where you might run into trouble if you used it wrongly.

Single Instance Roles only

Web deploy will only work on Web Roles with one single instance. This manifests in two possible ways:

1. If you try to enable Web Deploy for a Web Role with more than one instance, you will receive a warning message (below) and the deployment will actually only happen with one single instance in that role
2. If you increase the instance count from the Windows Azure portal after deployment, then Web Deploy will simply fail with an error code 550

Web Roles only

Web Deploy cannot be used to deploy incremental code updates to Worker Roles or VM Roles

Non-Persistent

Any changes you make to the running instance will not be persistent. They only affect the currently running instance of your web role. Should the running role ever need to be re-imaged, the deployment will be reverted back to its original state.

HTTPS Port when deploying from corporate networks

This is just a caveat and Anders had already outlined this in his article, but I would like to reinforce his point since I got burnt with it myself. There are quite a few corporate environments where HTTPS traffic is only allowed over specific ports (mostly limited to 443). Since Web Deploy uses HTTPS as a protocol, it may be required to change the Web Deploy port to 443 as outlined in Anders’ post. If that is the case in your particular network, this basically blocks you from deploying web roles that use port 443 themselves.

Bottom Line

All said and done, Web Deploy is simply awesome for Test and Dev. As soon as your troubleshooting and coding is finished, you should revert to using VIP swaps for all production use. See msdn.microsoft.com/en-us/library/ee517253.aspx for more details.

VIP swaps are slower to upload your new version (basically a fresh Staging deployment that needs to be up and running first), but will allow you a seamless transition between the old and the new version with near-to-zero downtime for your customers.