In this article, we are going to deploy Azure Resource Manager templates using Visual Studio Team Services, Microsoft’s cloud-based developers’ tool. We assume that you have Visual Studio and an account in Visual Studio Team Services up and running, and there is synchronization taking place between your local repository and VSTS. If you are not sure, we covered all those items in our previous article here at TechGenix.
Deploying the first resource in the ARM template
Assuming we started from a blank template, our first step is to open Visual Studio, connect with Visual Studio Team Services, and after we are connected open the existent project. Note: If you don’t have one yet, please create a new project and select Azure Resource Group and Blank Template. The results will be three files:
- JSON: The actual JSON file with all the code to deploy Azure resources
- parameters.json: The file with all answers defined in the parameters section of azuredeploy.json file
- ps1: PowerShell script that deploys both previous files using PowerShell from the workstation
We are going to start by opening azuredeploy.json, and by default, it will have the organization being shown in the middle of the depicted image with four sections: parameters, variables, resources, and outputs. If we pay attention, these same sections are represented on the left side in the JSON Outline tab, and we can use that to navigate easily in our future JSON file.
Creating the first resource using Visual Studio
The cloud administrator has several options to start an ARM template. We can get that from a new deployment in Microsoft Azure Portal, some templates on the Internet (GitHub), or even from Visual Studio.
Since we are exploring Visual Studio, let’s use the tool to create some basic resources to illustrate what we can do using Visual Studio. Right-click on Resources located on the JSON Outline tab, and click Add New Resource, from the list, select Virtual Network and label it. In our case we will use UCBoxVNET171, and click OK.
The result of that simple addition will be some code added to the variables and resources areas of the JSON file. By default, the subnets come with their IP ranges and names. We can change that on the JSON file to fit our environment. Keep in mind that information there is all we need to deploy a Virtual Network in Azure.
A simple way to deploy that JSON file in Azure is to right-click on the Project/Solution, located on the Solution Explorer tab, then click on Deploy, New…
In the new window, we have to define the subscription, the Resource Group (it can be an existent or create a new one), and define the files (the template, which is azuredeploy.json, and the parameters, which by default is azuredeploy.parameters.json). Click on Deploy.
The entire operation will be logged in the output area, and we can check the azuredeploy.json file was deployed successfully to the Resource Group that we created in the previous step.
Although a Successfully deployed template messages bring a lot of confidence to the cloud administrator, it is always good to check the results on the Azure Portal or using PowerShell. In the image below, we can validate that the Virtual Network (subnets are not being shown here but they were deployed) were created successfully in Microsoft Azure.
Using Visual Studio Team Services to deploy ARM templates
What we have just done it is useful when trying hit-and-miss settings or playing around with the template, but there is a more elegant way to deploy ARM templates using Visual Studio software and Visual Studio Team Services.
The first step is to log on to the Visual Studio Team Services portal and open the desired project (in our case VNETProject), click on Build and Release, and on the new page click on New Definition.
On the following page, leave VSTS Git selected on the Source, select the current Team Project, and select the repository for that project (we created a repo called VNETProject). Click on Continue. In the new page, click on the Empty process (first link from the top).
Add a task on Phase 1 by clicking on the + button. A list of all available tasks will be listed on the right side. Find Azure Resource Group Deployment and click Add.
Click on the new Azure Deployment:Create or Update Resource Group… on the left side. In the right side we need to fill out the information by selecting the Azure subscription, Resource Groups, and we will select from the current repository (using the … button) the two files generated in Visual Studio (azuredeploy.json and azuredeploy.parameters.json). They were already synchronized with Visual Studio Team Services. After making all the changes, click on Save & Queue, and a new dialogue box allowing comments will be displayed. Click on Save to confirm the changes.
The last step is to enable continuous integration. Click on Triggers, and select the project (VNETProject) on the left side, make sure to enable the option Enable continuous integration. Click on Save & Queue, and Save.
Using Visual Studio and continuous integration
Using Visual Studio and continuous integration requires a slightly different process to send the new code into production.
After finishing up your ARM template changes, click on Team Explorer, and Home icon. Click on Changes, write a description of the changes for future reference, and click on the drop-down and select Commit All and Sync. (This process performs the local sync, synchronization with VSTS, and makes sure that data is the same on both sides of the fence.)
Note: You can have better control by Commit All, then performing a Sync and last Sync, but in this case we just want to make sure that the data is the same, and we want to get the deployment going.
As soon as the synchronization process is complete, click on the home icon again, and click on Builds. Underneath My Builds, we will see that a build is in the process and it was triggered by our last synchronization. Double-click on it to find out more details.
A page in Visual Studio Team Services containing all the step-by-step information of the current build will be displayed, and from that point on the cloud administrator can see the progress or any eventual errors on the current deployment. On top of that, the result of the build will be sent by email (if registered on the VSTS profile) with the results.
Using the continuous integration feature in Visual Studio Team Services reduces complexity where the cloud administrator just needs to complete the ARM templates updates and synchronize. The VSTS will take care of the deployment and all steps will be tracked for future reference. Keep in mind VSTS was built for teams, so you can have your entire cloud team building resources in Microsoft Azure using this solution.
There are several advantages of using Visual Studio instead of manual deployment in corporate environments, but the teamwork, continuous integration, and the ability to track the changes are my top favorites.