This is the fourth part in a series demonstrating how to setup continuous deployment of an Azure Functions App using Azure DevOps build and release pipelines.
Demo app source code is available on GitHub.
In the previous instalment we created a build pipeline, defined the build steps using YAML, but when we tried to execute the build, it failed with the error:”buildConfiguration: command not found”. This is because in the YAML build definition we are referencing the $(buildConfiguration) variable which has not yet been defined.
An Overview of Azure Pipeline Build Variables
“Variables give you a convenient way to get key bits of data into various parts of your build pipeline.” [Microsoft]
Essentially variables allow you to define key/value pairs that can be used throughout the pipeline. They can be passed to YAML build definitions for use in steps, they can be accessed as environment variables in scrips and from unit tests, and can be used in the pipeline GUI when configuring tasks.
There are a whole host of predefined variables such as Agent.JobStatus, Build.BuildNumber, System.PullRequest.PullRequestId, etc.
You can also create your own custom variables.
Creating a Custom Variable in an Azure Pipeline
First off, open the build pipeline by clicking Builds, select the build pipeline you want to edit, and click the Edit button:
In the Variables section click Add:
For the variable Name enter “buildConfiguration” and for the variable Value enter “Release”, also check the “Settable at queue time check box”. This variable will default to “Release” but can also be set to “Debug” when manually queuing a build if you want to create a debug version of the Function App:
Notice the little padlock to the right of the value, clicking this enables you to store “sensitive values in a way that they cannot be seen or changed by users of the release pipelines” [Microsoft]
“The values of hidden (secret) variables are stored securely on the server and cannot be viewed by users after they are saved. During a deployment, the Azure Pipelines release service decrypts these values when referenced by the tasks and passes them to the agent over a secure HTTPS channel.” [Microsoft]
Another nice thing about designating a value as sensitive is that it will also be redacted in log messages produced by Azure Pipelines. Sensitive variables can also be passed to scripts – you should read the documentation and be careful about any custom logging or other output you create as you may inadvertently reveal secrets.
To save the changes, click the Save & queue dropdown and choose Save:
Once defined, build variables can be consumed in the YAML build template by using the token pattern $(VARIABLENAME), for example $(buildConfiguration):
- script: dotnet build 'src/InvestFunctionApp/InvestFunctionApp.sln' --configuration $(buildConfiguration)
displayName: 'Build solution'
Manually Queuing an Azure Pipeline Build
To queue up a new build, click the Queue button, optionally choose a branch/commit and click Queue. (Also notice here that it’s possible to set the buildConfiguration variable to a custom value for this build or leave it as the default “Release”):
Click the handy shortcut in the notification:
And this will take you to the build that should start executing.
Now that we have the custom variable defined, the build should now complete successfully:
Also notice that the steps in the build from “Build solution” to “Publish end to end test artifact” correspond to the steps defined in the YAML and that these are set using displayName: 'Run unit tests'.
In the next instalment of this series we’ll look at how unit tests are executed as part of the build pipeline.
If you want to fill in the gaps in your C# knowledge be sure to check out my C# Tips and Traps training course from Pluralsight – get started with a free trial.