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.

Building CSX files using VSTS

Azure Functions seem like a great idea to develop you microservices/APIs/gateways quickly and without too much overhead. They're scalable, can integrate with plenty of other Azure capabilities seamlessly and are really cheap. However, there's one problem when building your CI/CD pipeline - by default VSTS doesn't know how to build .funproj projects. Although it's easy to fix when building a project locally(by installing a SDK for Azure Functions), VSTS(and probably other build agents) is unable to do so and will greet you with sweet:

/
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AzureFunctions\Microsoft.AzureFunctions.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

The solution for this issue is pretty simple - we have to provide missing files to VSTS.

Helping VSTS

If you installed Azure Functions SDK locally you can go directly to:

/
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AzureFunctions\

You will find all missing .props and .targets file needed to build Function Apps. Copy all file from the directory and paste them somewhere next to your project. 

The last thing needed to is to modify .funproj file so it searches for the correct file. Open your .funproj file with any text editor and find <Import Project="..." /> lines. Currently they point to Program Files (x86) directory, what causes VSTS to fail when it tries to build your project because they're unavailable for it. Just change them to something like <Import Project="..\.build\Microsoft.AzureFunctions.Props" Condition="'$(VSToolsPath)' != ''" /> and <Import Project="..\.build\Microsoft.AzureFunctions.targets" Condition="'$(VSToolsPath)' != ''" /> and push to your repository. Now when VSTS tries to run another build, it will go green again.