Part 1 – General Overview & Account Structure.
Part 2 – Setting up the Azure and Visual Studio Online (VSO) structure and maintenance.
Part 3 – Setting up the Azure Environments with ARM and PowerShell.
Part 4 – Setting up Build Servers.
Part 5 – Setting up Continuous delivery (CD) on CI Development builds.
Part 6 - Setting up Release Manager for Dev nightly, QA, Stage and Prod deployments.

Part 3 – Setting up the Azure Environments with ARM and PowerShell for a single project.

A key component of continuous deployment is automating the creation and configuration of infrastructure. Having a reliable state to deploy to, in every environment, and removing manual work between builds that change infrastructure configuration is key to having short release cycles to production.

At the current time of writing, Azure is going through a gradual migration from the “Old” Azure portal to the new “preview” portal. As such, the way of administering different asset types varies greatly meaning you will ultimately be jumping between portals often. Powershell has been, until now, the preferred way of automating asset creation and tear down in Azure. However, as Microsoft have moved assets to the new “preview” portal they have opened up a new way of continuously deploying and configuring assets to Azure in the form of Azure Resource Manager (ARM) scripts. ARM script are a declarative JSON description of what assets and configuration you want to deploy to a given resource group. The scripts we build below will be reused later when we come to setup Release Manager.

1). Open the PowerShell IDE, and run the below commands 1 by 1 to switch to the correct azure mode (the PowerShell equivalent of new vs. old portal), log into your account, list all subscriptions in your account and select the correct subscription

Switch-AzureMode AzureResourceManager



Select-AzureSubscription -SubscriptionName "Department1 Development"

2). You now need to build your ARM script. This will vary project by project as to which azure asset types you require, but for now we will script a simple Web app. See the MSDN documentation over here on authoring ARM scripts from scratch. Alternatively there is a bunch of pre-made templates that you may find useful over here on Github. Visual Studio 2015 now has some inbuilt tooling for the creation of ARM scripts, but the tooling is early. Alternatively there is a web based ARM explorer over here. None the less the VS inbuilt tooling is a good starting point, so we will make use of it. See this blog post on MSDN for more details.

Tip: The preview portal uses ARM itself by default.If you hit problems with the ARM Script, open the Preview portal and pull up the dev tools in your browser (or Fiddler). If you create the assets manually you will see, after hitting the create button, the ARM request going out. This can be handy for reverse engineering.

2.1). Open VS2015 and open the project you checked into VSO earlier. Now add a new project to the solution, selecting Cloud then “Azure Resource Group”. Give you project a name and select OK.


2.2). On the next prompt select “Web App”


That will create the project structure below. Note the 3 folders, scripts, templates and tools. Open the templates folder and you will see 2 files, WebSite.Json and WebSite.param.dev.json. The first file contains the json description of our assets, while the param file contains input parameters that will be passed in at runtime (it is this file we will replace later when we use Release Manager). Now open the WebSite.json file, and don’t panic, it’s not as bad as it first looks. Note the toolbox on the left hand side, this will help you edit the json structure by adding in and building up the template you require; for now keep this simple with the default configuration. By default the WebApp has application insights added and performance alters, feel free to delete these if you do not require them. Personally I leave these in. Application insights is a cross of elmah error logging and Google analytics on steroids for all cross platform things in web, mobile app and cloud.


2.3). Open the param file and add some values to the siteName, hostingPlanName and siteLocation. These values will be replaced later when we configure Release Manager but this will get us up and running for now. SiteName and hosting plan name can be called anything you like (as long as it is unique and meets the naming restrictions for azure assets), while siteLocation should be the Azure datacenter closes to you – in my case North Europe. Note I have also added the SKU, at the top of our json file this is declared as an optional param with a default value.


2.4). Open the Deploy-AzureResourceGroup.ps1 file contained in the Scripts folder. Right Click the file and select “open with PowerShell IDE”. Currently, Aug 2015, there is a bug with Release Manager 2015 that means we are unable to run PowerShell Strict mode 2.0. You will receive the following error in your release manager build log if you do not perform this step “System.Management.Automation.PropertyNotFoundException: The property 'Length' cannot be found on this object. Verify that the property exists.”

You will hence need to update the PowerShell strict mode as below.

Set-StrictMode -Version 1.0

Tip: Release manager will always pass $UploadArtifacts as false, if you wish you can remove all the upload logic from the default script. Release Manager takes care of the upload for us so no need to have this as part of our script.

2.5). Execute this script by running the below command in powershell. Again it is this we will use later in Release Manager, it is worth sticking with PowerShell and not being tempted to run the JSON script through the Azure portal.

**PathToFile**\Deploy-AzureResourceGroup.ps1 -ResourceGroupLocation "North Europe"

Tip: if you require to clear down the resource group run Get-AzureResourceGroup _ResourceGroup_Dev_name | ForEach-Object { Remove-AzureResource -ResourceId $_.ResourceId -Force}

And that’s it, you should now have a dev environment in Azure… yes this is a simple example, but starting simple gives us a platform to build from.

Next up is configuring the Build servers so we can get our builds out onto the environment.