A week ago, I wrote a blog post on My Common ARM Templates, the first of a series of Azure Resource Manager (ARM) Templates that I am uploading to GitHub, as they are setups that I commonly use and hope they may be useful.
Building upon that blog post, I wanted to share the approach that I am taking to deploy those templates into my Azure Environment using Visual Studio Team Services.
I want to show you this end-to-end, so let's kick off by creating a new Visual Studio Team Services Project.
Once complete, the overview page is displayed for your newly created team project. Click on Build & Release in the top navigation bar, and then click Release in the sub menu.
Click on "New Definition", and select the blank Release Definition template.
We do not want to trigger the Release Definition from a build, so select "Choose later", and the appropriate agent queue for your project.
The page changes to your newly created Release Definition. Select the Artifacts tab, and click on "Link to Artifact Source".
Select GitHub in the type field. If you are creating a project from scratch, and have not yet set up any Service Connections - You will notice that the following inputs are not populated automatically. They are not complete because we do not yet have a connection to authorise our VSTS project with GitHub. We can go ahead and configure this by clicking on the Manage link.
You should now see the Services Endpoints section of our project. Click on New service Endpoint and select GitHub.
You are presented with the User Interface to create a GitHub service connection. You can either use OAuth to log in to your GitHub account or use a Personal Access Token to provide a controlled level of access.
I opted for the Personal Access Token route. You can create a Personal Access Token on GitHub. You will need to click the "Generate new token" button. You should see a series of access options. Select the appropriate options for your scenario, and click create. You will now have a Personal Access Token that you can use, back in Visual Studio Team Services.
Input your Personal Access Token into VSTS, and enter an appropriate name for the connection. One complete, you should now see a screen similar to the below.
At this point, you have now allowed your VSTS Team Project to access GitHub. With this, we can now go back and complete the link to GitHub as an artifact source.
You may need to close out the previous "Link an artifact source" popup, and set the flow off again. This time, you should see the GitHub items populated with your repositories. Select the repository that has the appropriate Azure Resource Manager templates hosted.
Now, let's navigate back to the "Environments" tab and add an "Azure Resource Group Deployment" task. You will notice that we need to setup a link to an Azure Subscription.
You can either click on the "Manage" link on the right-hand side to take you to the Services Connection Page (as we completed previously for GitHub). Or, you can open the drop-down and select the appropriate subscription based upon your current account credentials. You will need to authorise the link, by clicking the Authorise button that will appear.
If you opt for the "Service Connections" route, then you will see a similar approach to the below. As we are deploying an Azure Resource Group template, we will want to ensure that we are adding an Azure Resource Manager service endpoint, and not an Azure Classic endpoint.
As we continue completing the configuration information for the Resource Group Deployment task, we can select the ... for Template and Template Parameters. This will provide a popup that shows us the layout of our GitHub repository so that we can easily configure the paths to the appropriate files.
In this deployment task, you can override parameters with information passed in through Visual Studio Team Services. This is pretty cool because you can set variables in the VSTS platform to be used for this task.
For example, for my DevTest Labs ARM template, it requires a few parameters including environment, jenkinsVMCount, linuxVMCount, windowsVMCount, Password (For Windows Logins) and SSHKey (For Linux Logins).
To pass in these values, I enter the below into the "Override Template Parameters" field.
-environment $(environment) -jenkinsVMCount $(jenkinsVMCount) -linuxVMCount $(linuxVMCount) -windowsVMCount $(windowsVMCount) -password (ConvertTo-SecureString -String '$(password)' -AsPlainText -Force) -sshKey (ConvertTo-SecureString -String '$(sshKey)' -AsPlainText -Force)
You will notice that these parameters are all dependent upon variables. Let's now go and set those variables in VSTS, by clicking the variables tab.
(TIP: In my below example, I have only one environment, Test. If you had multiple environments, e.g. Dev, Test, QA and Prod, you could set variables on a per-environment basis. You can achieve this by clicking the ... next to the appropriate environment, and then choosing "Configure Variables")
Enter the appropriate names and values for your variables. For those sensitive settings, make sure to lock the padlock icon. This will ensure that future users editing the form are unable to view the sensitive information in plain text.
With that, we are now ready for a release! Save your Release Definition, and then go ahead and click into Release > Create Release.
You will now proceed through the workflow of setting up your release. You will need to select the most appropriate commit for your release, and how you would like the release to progress through your environments.
Fast forwarding ahead of time... If you have a valid Azure Resource Manager template, you should see a screen similar to the below. Congratulations, you have deployed your Azure Resource Manager templates from GitHub onto Azure!
For completeness, you can see the resources listed in my Azure subscription, as per the below screenshot.
I hope that this has been useful. Do you have any extra tips to share around Release Management, or working with Visual Studio Team Services and GitHub? Let me know on Twitter, @reddobowen!