Create Azure Cloud Service package in Visual Studio Team Services build

Question

We have an Azure Cloud Service with a web role and a worker role. We would like to setup continuous delivery in Visual Studio Team Services, automatically pushing out a build to Azure on source check-in. (QA environment). The source code is in Github. It's a best practice to no check in secrets to Github, so we are only checking in the .csdef file, not the .cscfg file(s).

What is the best way to create a build definition in VSTS which will pick up the .cscfg file from some other location and create the Cloud Service package? Where to store the .cscfg file and how to configure the build?

Answer 1

Solution: ended up using custom PowerShell scripts to replace configuration values in .cscfg file with VSTS variables. The configuration PowerShell scripts runs per environment defined in the release management pipeline. Note: variables defined as secret, will have to be passed as parameters to the PowerShell script, as the PowerShell script will not have access to those parameters using $Env:

Answer 2

We use Replace tokens task that's available in VSTS

You can also specify prefix and suffix for string replacement.

Then in your ServiceConfiguration.Cloud.cscfg , you would use the defined prefix and suffix to indicate what string to be replaced. The value of will be taken from Variables that you defined in VSTS. You will then put the name of the variable for this setting in between the prefix and suffix.

Example of ServiceConfiguration.Cloud.cscfg file that will be replaced by Password variable.

<Setting name="SqlPassword" value="#{Password}#" />

This can be used to convert / replace any string in any configuration file. One thing to note is that in some configuration files, the schema will validate the value of specific setting.

Such as case with ServiceConfiguration 's Certificate setting in Cloud Service. The value must be valid certificate thumbprint (that is any digit 0-9 and/or letter AF, lower and uppercase). The service configuration schema defined this and build will fail if the value doesn't meet the schema requirement.

To get around this, we have another task in our Release to replace certificate. The prefix / suffix for this could be something like abc and def , respectively. The name of the variable will be 001 . Unfortunately, it's not as descriptive because it has to be valid certificate thumbprint.

<Certificate name="MainSSL" thumbprint="abc001def" thumbprintAlgorithm="sha1" />