0 Comments

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 6 - Setting up Release Manager for Dev nightly, QA, Stage and Prod deployments.

As described in Part 5 we will be using Release Manager for our full pipeline. At the present time VSO does not have a web interface for us to administer Release Manager, although a new web interface is in the pipeline as announced at Build 2015 (skip to 28min in for a demo), however the good news is that we can do this currently via the desktop client tools that are used for on premise deployments. If you do not have it already, download and install Release Management 2015 from MSDN here (note MSDN Enterprise subscription required for this download). Most of what I describe below is covered in this channel 9 video over here.

1). Once installed, open release manager 2015 client tools from your desktop and you should be presented with the below screen. Enter your VSO URL (eg https://YourCompany.visualstudio.com) and click ok.

image

2). You will now be prompted to sign into your Live/work/school account associated with your VSO subscription. Note: you must sign in for the first time as the live account that is declared as the VSO Account owner, after that you can do to Administrator – > manage users –> new and add any additional users you wish.

Before we go any further with Release Manager setup, we first need to address some limitations of the current Release Manager as of Aug 2015. Unfortunately we are unable to directly deploy to App Service environments from Release Manager, but there is a workaround to allow us to do this. Release manager currently allows us to deploy to Virtual Machines via cloud services fine, hence we are going to use Virtual Machines (of which we will require one in every subscription we are deploying into), to bounce our build to the appropriate App Service (or indeed any azure asset) contained in that subscription. As we are likely to be doing the VM setup in more than one subscription it is worth scripting this, luckily I have went through this pain already so please find a couple of PowerShell functions that will help you do this over here.

Tip: Remember to execute the below PowerShell commands before executing the setup script.

Tip 2: Remember to exclude this new resource group from your clear down scripts.


Add-AzureAccount
Get-AzureSubscription
Select-AzureSubscription -SubscriptionName "Developer Tools"
Switch-AzureMode AzureResourceManager
New-AzureResourceGroup -Name BuildBounce -Location NorthEurope -Force
Create-BuildBounceVM -AzureSubscriptionName "Development" -VMName "bldbounce" -Location "North Europe" -StorageAccountName "buildbouncedev" -VMSize "ExtraSmall" -OSName "Windows Server 2012 R2 Datacenter" -VMUserName "Ouradmin" -VMPassword "MyPasswordIs-01" -ResourceGroupName "BuildBounce"

3). Step 2 above will take 10min or so to run. While we are waiting we can gather the information for the next step. To do this we will need to download the publish settings file from https://manage.windowsazure.com/publishsettings that contains our subscription details. Open this file with notepad once downloaded.

Note: this file does contain sensitive data, you will want to delete this as soon as you have retrieved the data we require.

4). We now want to give Release Manager access to all our Azure subscriptions we intend to deploy into. To do this, go to the Administration Tab – > Manage Azure then click on the New Button. Using the information from the publish settings file we just downloaded in step 3, add as many azure environments as you require. You can reuse the storage account that you created in step 2, make sure step two is complete before clicking save.

image

6). Now we have our subscription added, we can now setup our “Stage Types” in release manager. Go To Administration –> Manage Pick Lists –> Stage Type and click the Add button. A stage type is the stages your release will go through on its way to prod, this is usually a one to one mapping to “Environments” but not always. Add all that you need, I have added Dev, QA, UAT-Stage, Demo, Prod

image

7). We can now setup our “environments”, i.e the physical stages a release moves through. You will need at least one for each Azure subscription you wish to move your release through. Go to Configure Paths –> and click on New vNext: Azure.

image

8). The new environment template will appear, now select the “Link Azure Environment” button at the top right.

image

9). Under Azure environments select the appropriate subscription and you should see the VM/Cloud service we created earlier. If you don’t please double check that you created “Classic” VMs and not the current ARM style, at this point in time Release Manager only supports classic VMs.

image

10). Select the name of the VM you created earlier and select link.

11). You will now be taken back to the New vNext:Azure template window. Now click “Link Azure Servers” and select the full VM name (eg. vmbounce.cloudapp.net…) before clicking the “link” button.

image

12). You can now save your template. If you wish you can restrict this environment to a particular stage by selecting the “Stage Type Security”, this is optional.

14). We now require to setup the vNext Release Path, still under “Configure Paths” select the vNext Release Paths tab and select New.

image

15). Click Add, select your stage (i.e dev), the environment we just saved in step 14 and any approvers you require for this stage. For simplicity I have set these to Automated. Now click save and close.

image

16). Now select the Configure Apps tab (top right), then the Components tab (top left). Now select “New vNext”. In the Source tab under “builds with Application” add a single “\” to the build drop location. Give your component a name, and click save and close.

image

17).Before we go any further we need to create a XAML build definition (release manager at this stage only supports Xaml builds Sad smile ). To do this open Visual Studio, navigate to team explorer, click builds, and click new xaml build.Configure your trigger as desired, scope your “Source settings” to the lowest possible tree level you can, and in the build defaults tab select the classic build controller we setup on part 4 of this blog series. Now select the process tab and enter the below as additional arguments to MSBuild. This makes sure MS Build and Release manager can interop together.


/p:DeployOnBuild=True /p:AutoParameterizationWebConfigCOnnectionStrings=False

image

18). Now back over to Release Manager and select Configure Apps, then select the “vNext Release Templates” sub tab at the top left. Click New and give your pipeline a name, select the release path we created in step 14, and check the box “Can Trigger a Release from a Build”. You will also want to select the build definition, select the edit button and select the team project and build definition. Note if the build definition list is empty you will first require to create a XAML build, step 17.

image

19). Now right click components from the toolbox and click add, select the Component we create at step 16 and click the “Link” button.

image

20). Now drag the “Deploy Using Ps/DSC” action onto your template, double click on it, select your bounce server name, enter the username and password your created when creating the VM with the script at step 2 above. Select the component name we created at step 16, and set the PSScriptPath to “Configuration\publish.ps1”, scroll down the component and set the “SkipCaCheck” to “True”.

image

21). You should now have a pipeline to push a build into a given environment. To provision other environments simply repeat steps 2 – 20 above.

Summary:

In this post we have now completed the setup of an end-to-end development pipeline in Azure. You should now be able to successfully check into VSO and have your project built, tested and deployed into a Azure environment.