The recently refreshed Azure SDK v1.4.1 now supports the in-place upgrade of a single running Web Role instance using Web Deploy. This post details how to use this new feature.

The SDK refresh is available for download here: Get Started

As announced by the Windows Azure team blog,

Until today, the iterative development process for hosted services has required you to re-package the application and upload it to Windows Azure using either the Management portal or the Service Management API. The Windows Azure SDK 1.4 refresh solves this problem by integrating with the Web Deployment Tool (Web Deploy).

A common complaint regarding Azure has been that roles take too long to start up, and since every update to your software requires a start up cycle (provision, initialize, startup, run) the development process is slowed significantly. The Web Deploy tool can be used instead to upgrade an in-place role – meaning the core of an application can be refreshed in an iterative development cycle without having to repackage the whole cloud project. This means a missing CSS link, validation element, code behind element or other change can be made without having to terminate your Role Instance.

Note that Web Deploy is limited to a single Role Instance – if you have a complex website with multiple roles (which is more than likely in Production but maybe less likely in Staging if you are in a development cycle and working on the last stage before you deploy to Production) you cannot use Web Deploy. I suggest in this case that you should consider either a separate development instances where you can prove your technology before beginning to scale it, or you can always reduce the number of instances to 1, before then increasing the scale again to your chosen number. For other limitations, see here.

It is a useful streamlining of the Windows Azure deployment path as it bypasses the lengthy process of Startup. This must be considered when choosing whether to do a full deployment or a partial Web Deploy, for things such as Startup Tasks do not run when performing a Web Deploy. Any install task (for instance) has already been undertaken when the Role was initially created, and so does not execute again.

In this blog, I use the code from my previous blog, Restricting Access to Azure by IP Address. I use this blog as it includes a startup task that adds a significant length of time from the initial publish to the Role becoming available and responsive to browser requests. This delay is greater than the standard delay in starting an Azure Role as it installs a module into IIS. It is also these types of delay that the Web Deploy integration ask as a remedy for, as the start tasks do not need to be repeated on a Web Deploy.

Firstly, one has to deploy the Cloud Project to Azure in the standard way. This is achieved by right clicking on the Cloud Project and selecting “Publish”.

 

Standard Publish

Standard Publish

On this screen, those familiar with SDK v1.4 and earlier will notice a new checkbox; initially greyed out, this allows the enabling of Web Deploy to your Azure role. We need to enable this, and the way to do so is (as hinted by the screen label) to firstly enable Remote Desktop access to the Azure role. Click the “Configure Remote Desktop Connections” link, check the Enable Connections for all Roles and fill out all the details required on this screen. Make sure you remember the Password you enter, as you’ll need this later.

 

Set up Remote Desktop to the Azure Roles

Set up Remote Desktop to the Azure Roles

Once we have done this, the Enable Web Deploy checkbox is available for our use.

 

Check the Enable Web Deploy checkbox

Check the Enable Web Deploy checkbox

The warning triangle shown warns:

“Web Deploy uses an untrusted, self-signed certificate by default, which is not recommended for upload sensitive data. See help for more information about how to secure Web Deploy”.

For now I recommend you don’t upload sensitive data at all using the Web Deploy tool, and if in doubt, this should not be the preferred route for you to use.

Once you have enabled the Web Deploy for roles, click OK, and the deploy beings. This is the standard, full deploy that takes a while to provision an Instance and instantiate it.

From my logs, this takes 21 minutes. The reason for this particularly long delay is that I have an new module being installed into IIS which adds around 8 to 9 minutes at least to complete. Typically the deploy would take 10-15 minutes.

12:33:52 - Preparing...
12:33:52 - Connecting...
12:33:54 - Uploading...
12:35:08 - Creating...
12:36:04 - Starting...
12:36:46 - Initializing...
12:36:46 - Instance 0 of role IPRestricted is initializing
12:41:27 - Instance 0 of role IPRestricted is busy
12:54:12 - Instance 0 of role IPRestricted is ready
12:54:12 - Creating publish profiles in local web projects...
12:54:12 - Complete.

This 21 minute delay is what Web Deploy is seeking to reduce. I will now access my role.

You are an ip address!

You are an ip address!

We will now make a trivial change to the MasterPage of the solution, changing “You are: an ip address” to “Your IP is: an ip address”. This change requires a recompilation of the ASPX Web Application, and so could be cosmetic like this change, or programmatic or referential. Some changes are not possible with Web Deploy – such as adding new Roles, changing startup tasks and changing ServiceDefinitions.

In order to update our code, right click on the Web Role APPLICATION Project in Visual Studio. This is different to the previous Publish, which was accessed by right clicking on the Cloud Project. Select “Publish”.

 

Web Deployment options

Web Deployment options

All of these options are completed for you, although you have to enter the Password that you entered when you set up the Remote Desktop connection to your Roles.

Clicking Publish builds and publishes your application to Azure. This happens for me in under 5 seconds.

========== Publish: 1 succeeded, 0 failed, 0 skipped ==========

That is that. It’s amazingly quick and I wasn’t even sure it was working initially:-)

Going to the same Service URL gives the following:

 

An updated web app!

An updated web app!

As you can see, the web application has been updated. We have gone from a deployment cycle of 21 minutes, to an iterative deployment cycle of 5 seconds. AMAZING.

One last thing to note, straight from the Windows Azure Team Blog regarding constraints on using Web Deploy:

Please note the following when using Web Deploy for interactive development of Windows Azure hosted services:

  • Web Deploy only works with a single role instance.
  • The tool is intended only for iterative development and testing scenarios
  • Web Deploy bypasses the package creation. Changes to the web pages are not durable. To preserve changes, you must package and deploy the service.

 

Happy clouding,

Andy