Connect a release to a build in VSTS

For some reason there's no easy way to connect a release to a build when using REST API provided by VSTS. Something which should be fairly trivial seems like a task, which is impossible to finish. However there's a "dirty" way of finding a build identifier, which is related to a release we're interested in.

Digging into release data

Let's consider following request:


When called it'll returns a detailed information about a release including approvals, deployment steps, workflow and many more. When you dig deeper into a response, you'll find one section, which may help us here:

"artifacts": [{
	"sourceId": "{sourceId}",
	"type": "Build",
	"alias": "some_alias",
	"definitionReference": {
		"artifactSourceDefinitionUrl": {
			"id": "https://{account}",
			"name": ""
		"definition": {
			"id": "{definitionId}",
			"name": "Name"
		"project": {
			"id": "{projectId}",
			"name": "Name"
		"version": {
			"id": "5854",
			"name": "2017.97"
		"artifactSourceVersionUrl": {
			"id": "https://{account}",
			"name": ""
		"defaultVersionType": {
			"id": "selectDuringReleaseCreationType",
			"name": "Specify at the time of release creation"
		"branch": {
			"id": "refs/heads/develop",
			"name": "refs/heads/develop"
	"isPrimary": true

Of course I obscured it a little, but you should be able to get the picture. In the artifactSourceVersionUrl property you can see a URL, which itself isn't helping much. What we're interested in is the very end of it - it the query string it contains a buildId key, which directly points to the build used for this release. The only thing you have to do is to parse the JSON and extract identifier, which can be used further to query for a build.


Although REST API provided by VSTS is really helpful in most cases, this time I was really confused. Fortunately even indirect solutions are still solutions so as long as there's no other API version, this workaround seems valid uncomplicated.

Finding deployment credentials of your Web App in Azure

When a Web App is published to Azure for the first time, publish profile is being generated containing basic information regarding what, where and how should be deployed. After you've automated your CI/CD pipeline, those informations are somehow lost. But what if I need to incorporate them in my build or release process? Fortunately there's an easy way to download all the data and use it for our purpose.

Azure CLI for the rescue!

To be honest, there's a few Powershell commands, which could help us here at least like:

  • Get-AzureWebsite
  • Get-AzureRMWebApp
  • Get-AzureRMWebAppPublishProfile

The first one is designed for Azure Classic and won't work e.g. when a connection type in VSTS is set to Azure Resource Manager. However it allows you to get credentials really easily:

$website = Get-AzureWebsite -Name $functionAppName

$username = $website.PublishingUsername
$password = $website.PublishingPassword

It will work perfectly if only you're not restricted to using ARM.

Get-AzureRMWebApp is a command, which is designed for working with Resource Manager. It's very similar to Get-AzureRMWebAppPublishProfile, the difference comes from the amount of information it returns. Since in this post we're focusing on getting deployment credentials, we'll skip the former and consider the latter only. When Get-AzureRMWebAppPublishProfile is called, it returns XML content, similar to .PublishSettings file which can be downloaded from Azure Portal. To fetch both a username and a password, you can use following script:

$xml = [xml](Get-AzureRMWebAppPublishingProfile -ResourceGroupName $resourceGroup -Name $functionAppName -OutputFile "__deploymentProfile.xml" -Format WebDeploy) 
$publishProfile =  $xml.FirstChild.ChildNodes[1]

$username = $publishProfile.userName.split('\')
$password = $publishProfile.userPWD

With those credentials, you can automate your CI/CD pipeline even more(e.g. they are needed when accessing Kudu for a master key for Azure Function). The only thing you have to remember, is to select the right version of the command, depending on the deployment model.