Deploy automatically to virtual machines in Windows Azure using Visual Studio Release Management
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
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:
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.
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.
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:
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.
You are now ready to deploy automatically to your Azure’s VM.