Azure Resource Group Deployment using Visual Studio Team Services (VSTS)-Part 1

Visual Studio Team Services provides a set of cloud-powered collaboration tools that work with your existing IDE or editor, so your team can work effectively on software projects of all shapes and sizes.

In this topic let’s see how we can auto provision the resources on Microsoft Azure using Visual Studio Team Services capabilities.

Firstly, I would like to discuss about the Pre-requisites needed in order to accomplish this task-

  1. VSTS account
  2. Microsoft Azure Subscription
  3. A sample project (.NET, Java etc.) in my case it’s a .NET project
  4. ARM Templates which is available on the following link-

https://github.com/Azure/azure-quickstart-templates/tree/master/101-vm-simple-windows

Assuming that all the Pre-requisites are in place let’s start.

The following steps will walk you through the necessary configuration for ARM deployment using Visual Studio Team Services

Firstly navigate to https://www.visualstudio.com/

1

Upon signing in, you get the list of accounts if created earlier or you can always create a new account-

2

After navigating to the account, a dashboard would appear for the Team Project that you have selected-

3

To setup Azure Service end point in VSTS, from your Visual Studio Account, navigate to your Team Project and click on gear icon

4

Click Services tab and click on ‘New Service Endpoint’ in the left pane

5

In the drop down, select Azure Resource Manager-

6

A dialog box appears for which you will have to enter the following details-

  • Connection Name
  • Subscription Id
  • Subscription Name
  • Service Principal Id
  • Service Principal key
  • Tenant ID

7

If you don’t have the following details, you can download and run the Power Shell script from the below link which will give you the above details-

Download here

Or you can also download from here-

SPN

NOTE- Change the extension of the above file to .ps1 and execute

After adding the Endpoint, navigate back to your account. Make the changes to your ARM template as shown below-

Change the names of your VMName, VMSize, Vnet etc- in the deploy.json file

8

Also add the credentials to your deploy parameters.json file as shown below-

9 After doing the changes to the files, check-in to your VSTS and you should be able to see in your VSTS repository under the project that you are deploying-

10

Setting up the Build Definition

Navigate to the Build hub and create a new definition by selecting empty template-

11

Add the desired build steps as shown below from the build library. In my case I am building a .NET project so I have added couple of tasks for the same-

12

Note- You can either use the Hosted service provided by Microsoft for initiating the build or you can configure your own Private agent. For configuring the build agent please follow the below link which gives you step-by-step procedure to do so-

https://msdn.microsoft.com/en-us/library/vs/alm/release/getting-started/configure-agents

In my scenario, I have made use of Private agent (Contoso)-

13

After adding the tasks, lets configure. So I am configuring my 1st task i.e Visual Studio build-

  1. Map the .sln file for which you have to build the application
  2. Specify the MSBuild arguments based on your requirement. In my scenario, I am building and creating a package file for my deployment.

Here is the arguments for the same-

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true           /p:SkipInvalidConfigurations=true

3. Specify the configuration and platform for you to have the build with

14

4. If you wish to have multi-configuration setup, to run parallel builds, check the following options or else leave blank-

1

5. Choose the repository to map your project. In my case, i have TFVC and mapped it to Tailspin Toys Project-

2

6. If you wish to parameterise your build, then add the pre- defined variables here else retain as it is-

3

7. Choose the Trigger options like if you want to have CI builds or gated check-in builds or scheduled builds etc. and select accordingly-

4

8. Retain this configuration as it is or you can modify to change the build number format etc-

5 9. Setup the retention policy as per your needs-

6 10. View the history of all the builds which were completed-

7

11. Upon running the successful build, we get a summary of our build whether it’s passed or failed or partially succeeded-

8

12. You can also view the test results that were associated as part of the build-

9

13. Verify whether the build artifacts are created or not by navigating to the artifacts hub in the build summary-

1

So in my case a .zip file (Tailspin.Web.zip) file is created which i would be using for my further deployments.

The Release workflow will be shared soon in the next part.

Thanks,
Srivatsa

Leave your replies below for any queries, i will try to respond at the earliest 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: