An Azure DevOps pipeline is essential if we want to setup continous integration (CI) or continous deployment (CD) in Azure.
Before we can release our .NET application to production, we need to create a build pipeline. A build pipeline is responsible for checking out the code from a source repository, such as GitHub.
From there, it can use an agent to install NuGet, restore the NuGet packages, build the application, run unit tests and publish to an artifacts file.
The build pipeline uses a YAML file to build a list of tasks to complete the build pipeline.
In this beginners tutorial, we'll have a look at how to build a Azure DevOps pipeline for an ASP.NET Core application. We'll also have a look at some of the other options, such as environment variables.
Azure DevOps account
Before we can even think about building our application in Azure, we need to setup a Azure DevOps organization.
With our Azure DevOps project setup, we can go ahead and create our build pipeline. Inside our project, it's a case of going into the Pipelines section, and creating a new pipeline.
The first thing we need to do is to connect up to the source repository that hosts our ASP.NET Core application.
Azure Pipelines supports a number of external source repositories, like BitBucket and Subversion. However, for this demo, we'll going to use GitHub, and we need to login to GitHub, select the repo that we want to use and authorise it with Azure DevOps.
Once that has been complete, we're asked to configure our pipeline. There are a number of templates we can select from, and a azure-pipelines.yml file will be created and will be saved in the root of the repo.
For this demo, we'll select Starter pipeline. That will take us to our azure-pipelines.yml file. We're going to go ahead and delete all the contents from the YAML file (with the exception of the comments at the top). We need some content in the file in-order to save it.
Build the pipeline
We are going to have a look at a number of YAML keys that we can use to build up our pipeline and publish our application to an artifacts file.
In-order to setup continous integration (CI), we need to setup a trigger. CI is when a build is triggered everytime a commit is made to a repo's branch.
If we wish to trigger a build everytime a commit is made into the main branch, we would add it like this.
However, we may wish to turn this off whilst setting up our build pipeline. The likelyhood is that everytime our YAML file is saved, it will commit to the branch that we are triggering. As a result, it will create a new instance of our build pipeline everytime the file is saved.
With NuGet installed, we can go ahead and restore the packages onto our virtual machine agent. Inside this task, we have a inputs:restoreSolution key. We want to set this to the Visual Studio solution file. As we set the solution file as a variable, we can reference that variable by calling $(solution).
With the tests successful, we can go ahead and publish the application.
Once again, we can use the .NET Core CLI. But this time, we will use the publish command.
We also need to add a parameter to our argument. The --output parameter tells us where to deploy the application to.
For this, we want to publish it to the artifact staging directory. This is the location that we'll use to publish the artifacts file to Azure Pipelines. The $(Build.ArtifactStagingDirectory) is a variable that will output the artifact staging directory, so we can use this in our --output parameter.
In-addition, we also need to use the inputs:projects key to state which solution or project we want to build. If we state a project, and our solution has two or more projects in it, we need to set inputs:publishWebProjects to false. Otherwise it will ignore the value in the input:projects key, and it will just find the first project that it comes across.
As we stored the project as a variable, we can reference it by calling $(project).
With the web application published to the artifact staging directory, it's a case of publishing the build artifacts to Azure Pipelines. The artifacts can be used for the release pipeline, so this will be the final task that we run in the build pipeline.