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 4 – Setting up Build Servers.

Now we have an azure environment, we need some way to build our assets before deploying them out there. With VSO we currently have 2x2 options. 2x2? yes, see the below grid and note a mix and match from each column.

TemplatesControllers
VNextHosted
XamlOur own VM

VSO and TFS2015 introduced new build templates that are night and day better than the old xaml ones, for an overview of why see Colin Dembovsky blog post. While Xaml builds are still currently supported it would appear they finally seem to be headed for the retirement home. The other 2 options we have with VSO is whether to use the hosted build controllers provided by VSO or provision our own VMs for building what we have defined in our templates (whether that is xaml or vNext). After some extensive testing, that is a blog post on its own, we came to the conclusion that at present the hosted build controllers are simply too slow for anything more than a couple of developers (20 times slower is some cases) – since this is an article on moving Enterprise to the cloud, our dev numbers are likely to be in the 10’s to 100’s. Due to the pricing model of “build minutes”, and just how dramatically slow the hosted builds are, the hosted build controllers on any non trivial project are equally as expensive as provisioning the VMs yourself.

Setting up the Build Server:

Luckily a Microsoft engineer, Thiago Almeida, has made setting up a build server and attaching it to VSO incredibly straightforward by providing an ARM template on his GitHub repository. Before using this though we have to setup Alternate Authentication Credentials on our VSO account so our build agent can access our VSO account.

1). Go over to your VSO account and sign in as a service account (a generic user you have setup for this purpose) with admin rights across the full VSO collection.

image

1.1). Click your name /the service accounts name and select my profile

image

1.2). In my profile select the security tab, then “Alternate Authentication Credentials”.

image

1.3). At the present time the build controller setup will not work with Personal Access Tokens, hence override this warning below and check the “Enable Alternate Authentication Credentials”. Now enter a username and password and click “Save”.

image

Setup Agent Pool (optional)

2). You can create a custom group that holds your build agents together. This can be useful if you plan on creating build agents in azure and on premise.

2.1). To do this go to the Agent Pool Admin panel at https://VSOUSERNAME.visualstudio.com/_admin/_AgentPool and select “New Pool”

image

2.2). Enter a pool name and click ok, note down this name for later.

Deploying the Build VM

3). Open up the PowerShell IDE on your desktop and run the following commands. This will first prompt you to log in, then display a list of all subscriptions your account has access to, and then selects the appropriate subscriptions that we wish to run our script in, before finally switching PowerShell over to the new mode.


Add-AzureAccount
Get-AzureSubscription
Select-AzureSubscription -SubscriptionName "Developer Tools"
Switch-AzureMode AzureResourceManager

3.1). We can now execute the below line of PowerShell which will use the given template provided by Thiago and deploy the assets into a resource group named “BuildServers”.


New-AzureResourceGroupDeployment -Name BuildServerSetup -ResourceGroupName BuildServers -TemplateUri https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/visual-studio-vsobuildagent-vm/azuredeploy.json -vmVisualStudioVersion VS-2015-Enterprise-AzureSDK-2.7-WS2012R2

PowerShell will now prompt you for all parameters required by the script. Note: it will take many minutes for Azure to spin this environment up. Pay careful attention to the parameter guidelinesover here

image

Here is what I provided:

ParamValue
StorageNamecompanybuildserverstorage
deployLocation“North Europe”
vmNameCompanyBuildServer01
vmAdminUserNameadmin
vmAdminPassword***********
vmIPPublicDnsNamecompanybuildserver01
vsoAccountcompany
vsoUserThe user created above
vsoPass*********
poolName“Default”

Tip: use the following to clear down the resource group if you require multiple runs of the above.

Get-AzureResourceGroup BuildServers | ForEach-Object { Remove-AzureResource -ResourceId $_.ResourceId -Force}

3.2). An alternative to 3.1 above, is to hit the button below which will take you into the azure portal to deploy the ARM script manually. I would recommend 3.1 though; getting used to PowerShell, if you are not already, will make your life on Azure much easier.

3.3). You can now go back over to the Agent Pool admin page and expand the Agent pool you created, or the default pool if you did not. If the script was successful you should now see your new Build Server under the agent pool. If you don’t see this make sure you are part of the Team Foundation Server administrators group and try again.

Deploying a XAML Build Agent

Unfortunately in order for us to use Release Manager online, as of Aug/Sep 2015, we will require our builds to be XAML based and as such we can’t fully switch over to the nice new “Team Build vNExt” system. As such we must configure our VM we created at point 3 with a XAML build agent.

4). Firstly remote desktop (RDP) onto the build server you just created and download TFS 2015 from MSDN here.

4.1). Now run the TFS 2015 setup and when prompted select “Configure XAML Build Service” and select “Start Wizard”.

image

4.2). Select your feed back participation options on the next screen and click next.

image

4.3). You will now be asked to configure which TFS instance (VSO in our case). Select Browse, then servers, then add and enter your VSO address in the format https://YOURID.visualstudio.com

image

4.4). Click ok and you should be asked to sign into your live account, use and id with admin rights, and click login. If you are successful you should see the below screen.

image

4.5). Click on Close and then “Connect”.

4.6). You will now be taken back to the build service configuration screen, now click next.

image

4.7). On the next screen you will be prompted to select the amount of “Build Agents” you wish to place on this server. TFS best practice says 1 agent per core available on the CPU, but since this is azure and we can scale when we need, override the recommended and select “4” and click next.

image

4.8). You will now be prompted to select the account to run the agents as. You may wish to setup a custom user in your AD, but using the system account Local service should suffice in most cases. Select this and click on next.

image

4.9). Click on next again on the “review” screen, and the installer will run some checks. If all is successful you will be displayed with the below screen, click “Configure”.

image

4.10). Everything being ok you should now be presented with the below screen. You can now exit the wizard, a XAML build server should now be visible to you through the XAML Build templates created through Visual Studio.

image

Summary:

In this post we have setup a VM in Azure, setup a vNext build controller on that VM, and then setup a XAML build agent on that same VM and made them all available inside VSO to accept builds. In the next post I will show how we setup the build templates for the project.