Introduction
I was recently doing the talk on Terraform and Azure Pipelines at the UK Cloud Infrastructure User Group and a number of people asked if I could write up a blog on Terraform and Azure Pipelines. We’re also testing out Azure Durable Functions so I figure that I’ll write about deploying .NET Core Azure Durable Functions using Terraform and Azure Pipelines.
Azure Durable Functions
To get more information about Azure Durable Functions, see here.
This series is more around the Azure Durable Function deployment rather than the durable function .NET core app itself so we won’t go into much detail however what I can tell you is that this durable function is triggered by an HTTP request, accepts a name value and it just responds with “Hello <name>!”.
Terraform Configuration
Terraform is a great alternative to ARM Templates. Compared to JSON, Hashicorp Configuration Language (HCL) is much simpler and pretty much human-readable. You can find out more about Terraform by going to https://learn.hashicorp.com/terraform or my Terraform presentation here.
There is a Terraform configuration in the same GitHub repo as the Azure Durable Function and we’ll use this configuration to deploy a Function App to Azure which will use the Consumption Plan. The Terraform configuration deploys a new resource group, app service plan, storage account and function app (V2).
Azure DevOps has a cool feature where you can write out your Azure Pipeline build definition as code using YAML. This has the benefit that the build configuration is now stored in source control with the application code itself so you get all the benefits of versioning and peer review through pull requests and you can keep your application code and the build definition in sync. You can read more about pipelines as YAML here.
The resources section specifies that the code we are running tasks against is the same repo that the YAML file is stored in (self). We will also clean the build directory before starting our build.
The pool section specifies that we’ll use the hosted Visual Studio 2017 on Server 2016 hosted build agent.
In the variables section, we’re specifying that the variable buildConfiguration is set to Release. We’ll use this variable when running our dotnet CLI commands.
In the repo, there’s a few folders as below.
The YAML for the terraform build and test looks like below:
We’ve now built and tested both our application and terraform code and are ready for the release stage however we first need to output some artifacts to pass through to the release. Below are the tasks to publish these artifacts:
Both tasks are using the Publish Build Artifacts Azure DevOps task templates and are simply specifying the path to publish and the name for the artifact. When run, this would output two artifacts – one called app and one called terraform.
Azure DevOps build definition as YAML
Azure DevOps has a cool feature where you can write out your Azure Pipeline build definition as code using YAML. This has the benefit that the build configuration is now stored in source control with the application code itself so you get all the benefits of versioning and peer review through pull requests and you can keep your application code and the build definition in sync. You can read more about pipelines as YAML here.
You can find the full YAML pipeline file in the repo here but we’ll go through each part in turn. To get started, the first part of our YAML file needs to look like this:
The resources section specifies that the code we are running tasks against is the same repo that the YAML file is stored in (self). We will also clean the build directory before starting our build.
The pool section specifies that we’ll use the hosted Visual Studio 2017 on Server 2016 hosted build agent.
In the variables section, we’re specifying that the variable buildConfiguration is set to Release. We’ll use this variable when running our dotnet CLI commands.
Build a .NET Core app using Azure DevOps Pipeline as YAML
In the repo, there’s a few folders as below.
- AzureDurableFunctionsDemo1: Contains the .NET Core project that includes the Azure Durable Functions
- AzureDurableFunctionsDemo1.Tests: Contains a .NET Core project that includes tests for the methods in the Azure Durable Functions Demo 1 project
- Deployment: Contains a terraform folder which includes the terraform configuration
In order to build and test our app, we need to do as we would for any .NET Core application – i.e. build, test and publish. Using the Azure DevOps pipeline as YAML, this looks like below:
Notice the steps keyword here – we only need to specify this before the first task in the build pipeline.
- Build: This task is using the .NET Core CLI Azure DevOps V2 task template and it’s specifying that we want to build all projects using the configuration parameter which is set to the buildConfiguration variable which itself is set to release.
- Test: This task is using the same task template but is only running tests in projects which include test in the project folder name. It’s also publishing the test results to Azure DevOps as the publishTestResults parameter is set to true.
- Publish: Again using the same template, this task publishes only the AzureDurableFunctionsDemo1 project and it publishes it to the artifact staging directory on the build agent which is specified by the built-in Azure DevOps variable build.ArtifactStagingDirectory. We don’t have any web projects to publish so publishWebProjects is set to false however we do need to publish a zip file for deployment to Azure Functions so we’ll set zipAfterPublish to true.
That concludes the build and test for the .NET core app so let’s move on to building and testing our terraform configuration.
Build a terraform configuration using Azure DevOps pipeline as YAML
The YAML for the terraform build and test looks like below:
- Terraform Install: As we’re using the Visual Studio 2017 hosted build agent which doesn’t have terraform installed on it so you’ll see the first task is a Terraform Install task which uses chocolatey to install terraform: choco install terraform. This task uses the Command Line V2 task template in Azure DevOps.
- Terraform Init: With terraform, we don’t need to build/compile it as we do for a .NET app but we can run some basic form of unit tests on it by using terraform validate however before we run this, we need to initialize terraform which we do by running terraform init. We’re setting input to false because we don’t want terraform to prompt us for any missing variables as this is an unattended command and we’d want it to just fail instead. We’d use a backend configuration to specify the location for the remote state file when we’re running the configuration however we’re just validating our terraform in this case so we’ll set the backend to false.
- Terraform Validate (Dev): For this task, we need to specify all the variables that terraform would expect when we attempt to deploy an infrastructure. These don’t need to be the exact values but they need to be the correct type of variable (string, array or map) so as we just have strings, we can just set them to test. You’ll see that we’re specifying the envDev.tfvars file so that terraform validate can validate the variables which are set in this file. This task has no output unless there’s a problem with the validation where it provides a non-zero exit code which fails the step in the pipeline.
In both the Terraform Init and Terraform Validate (Dev) tasks, you’ll see that we’re specifying the terraform configuration path as deploymentterraform which is the relative path to our terraform configuration.
Publish the .NET Core app and terraform configuration
We’ve now built and tested both our application and terraform code and are ready for the release stage however we first need to output some artifacts to pass through to the release. Below are the tasks to publish these artifacts:
Both tasks are using the Publish Build Artifacts Azure DevOps task templates and are simply specifying the path to publish and the name for the artifact. When run, this would output two artifacts – one called app and one called terraform.
Save the YAML pipeline
The last step is to save the YAML pipeline as azure-pipelines.yml and store this in the root of the repo.
Conclusion
In this post, we’ve gone through the YAML build definition to build and test a .NET Core Azure Durable Function and terraform configuration. In part 2 we’ll go through how to create the Azure Build in Azure DevOps.