Deploy automatically to virtual machines in Windows Azure using Visual Studio Release Management

Anand Gaurav

April 2nd, 20140 0

Visual Studio Release Management can be used to achieve continuous deployment to virtual machines in Windows Azure. When configured correctly, Release Management is able to deploy to a VM residing on the cloud just as easily as to a VM hosted locally. This article will explain the steps in order to start a VM on the cloud, deploy to it, and stop it once it is not needed anymore.

When deploying to a VM on the cloud, it might be required that you start or stop the VM. Stopping a VM between releases is useful to avoid consuming Azure’s resources. Starting and stopping an Azure’s VM requires installing a proxy Release Management Deployer and installing Azure’s credentials and tools on the same machine.

Let’s first configure the proxy Release Management Deployer. A Release Management Deployer can be installed on any machine that has access to Release Management server. This proxy Deployer will be the one receiving instructions to start (or stop) the VM that resides on the cloud.

If Windows Azure PowerShell cmdlets is installed and properly configured on the proxy deployer (subscription is imported with the right credentials), you can go directly to step 4.

Step 1 – Create Windows Azure Account

In this step, you need to get a Windows Azure account. You can get the Windows Azure 90-days free subscription with no cost or obligations at http://www.windowsazure.com/

Step 2 – Install Windows Azure SDK for .NET

We now install Windows Azure SDK for .NET on the proxy Deployer machine. It is available here.

You need the .NET Framework 4.5 – available here and Windows Azure Powershell.

Step 3 – Setup credential in Windows Azure PowerShell

Still on the proxy Deployer machine, we now configure the Windows Azure account to be able to execute Azure PowerShell Commandwithout specifying credentials when executing commands.

1. Open Windows Azure PowerShell

Execute this commands:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Get-AzurePublishSettingsFile

2. Sign in

3. Download and save the .publishSettings file locally

Security note: This file contains an encoded management certificate that will serve as your credentials to administer all aspects of your subscriptions and related services. Store this file in a secure location or delete it after you finished these steps.

4. Import the downloaded .publishSettings file by executing the following command:

Import-AzurePublishSettingsFile "<publishSettings-file>"

5. Link the Subscription to Storage Account

In order to link the storage Account to the subscription, we need to know the name of the Storage Account created by default for your Windows Azure Account.

Go to Windows Azure | Storage

Once we know the name of the Storage Account, use this command to link to your subscription:

Set-AzureSubscription –CurrentStorageAccount "<currentStorageAccount>" –subscriptionName "<subscriptionName>"

6. We also want to set this subscription as the default one.

Select-AzureSubscription -Default "<SubscriptionName>"

7. Use this command to get the subscription information.

Get-AzureSubscription

Make sure the CurrentStorageAccount is set with your Storage Account name and the IsDefault attribute is set to true.

Your machine is now ready to run Windows Azure Powershell.

Step 4 – Configure Release Management to deploy to virtual machine in Azure

We will now configure Release Management to allow deployment to the virtual machine in Azure.

1. Prerequisites

a. Azure’s VM must be started

b. Because Windows Azure resides outside your network, you will need to publish the Release Management Server endpoints through your firewall. Release Management supports secure connectivity over HTTPS. The easiest way to manage this is to use a Reverse Proxy and let it redirect all incoming HTTPS traffic to the Release Management Server endpoints. Internally, Release Management can be configured to run over HTTP. It is the job of the Reverse Proxy to convert all HTTPS traffic to HTTP when directing requests to Release Management. Once published, you can configure the Release Management Deployer that lives in your Azure VM to connect to Release Management over this public endpoint.

c. Release Management deployer must be configured in the Azure’s VM (service started with sufficient privileges).

2. Open Release Management

3. Create a New Server, Configure Paths | Manage Servers | New

4. Enter the name of the VM as the server’s Name

5. Set the Drop Location Access to Through IR Server over HTTP so that all files that have to be transferred will be sent through the Release Management Server (in that case, the VM on Azure does not need access to the drop location).

6. Complete other needed information and Save.

7. Create any number of components that needs to be deployed to Azure through Configure Apps | Components | New

8. In the release template, add the components needed to deploy over the Azure’s VM

Final configuration of the Release Template could look like similar to this:

Development Stage	QA Stage	Production Stage

Things to notice from this configuration:

Before installing a component (WebServicesComponent in this case), we make sure the VM is started.
The target server for the actions Start VM in Azure and Stop VM in Azure is always the same proxy server.
The Start VM in Azure and Stop VM in Azure uses Configuration Variables to indicate which VM to start and stop.
The Stop VM in Azure action (through its Configuration Variables) always stops the previous stage’s VM. That is why it is turned off in stage dev (there is no previous stage). Stopping a VM in the next stage will allow us to do the installation, then the required testing and turn it off once we deploy to next stage. Note that stopping the VM is optional since concurrent testing may be required on the different stages. It can also be managed manually.
The Start VM in Azure action of stage prod absent as we assume this VM is never stopped.