This article will present the process of configuring Azure DevOps Services to an existing project. Our development flow is somehow similar to the Git-Flow in the way that we have two main branches
develop and we’re going to to trigger CI/CD operations on new commits that are pushed to these branches. For this purpose, we are going to use Azure Pipelines.
Azure Pipelines is free for public projects, but if you use private projects, you can run up to 1,800 minutes (30 hours) of pipeline jobs for free every month. Learn more about how the pricing works based on parallel jobs.
Creating a new Pipeline
To start, we create a new Pipeline using
Create Pipeline button and choosing the appropriate repository on an existing project.
On the next page it shows a couple of Pipeline templates to use from.
If you’re creating a whole new pipeline from scratch these templates are a good starting point. If you already have a YAML file then you can chose the
Existing Azure Pipelines YAML file and on the next page choose the appropriate YAML file.
After choosing the proper pipeline template (for example .NET Desktop), we are presented with the YAML preview page in which we can modify the generated
.yml file. Here we can see actual steps of our Pipeline. A step is the smallest building block of a pipeline. For example, a pipeline might consist of build and test steps. A step can either be a script or a task. A task is simply a pre-created script offered as a convenience to you.
YAML is a storage human friendly serialization standard (like JSON) which basically contains key value pairs. Here we are using it to describe different properties of the Pipeline. The first property is the
trigger property. A trigger is something that’s set up to tell the pipeline when to run. You can configure a pipeline to run upon a push to a repository, PR creation, at scheduled times, or upon the completion of another build. Note that YAML PR triggers are currently only supported in GitHub and Bitbucket Cloud. If you are using Azure Repos Git, you can configure a branch policy for build validation in order to trigger your build pipeline for validation. As it can be seen the default trigger is set to build upon push to the
Next, there is some configuration like
vmImage to be used for build and some variable declarations, followed by the actual steps for our Pipeline in the
A couple of steps are per-defined for us by the template. In this example the steps are:
NuGetToolInstaller : Fetches the proper NuGet tools required by the next step.
NuGetCommand : Installs the dependency packages.
VSBuild : Builds the solution.
VSTest : Runs the tests.
Each task is followed by a number which defines the version of that task. For example
VSTest@2 means version 2 of the
Also the YAML editor adds a little button called
settings which we can use to modify the tasks visually.
If you’re happy with the configs you can click
Save and run which will create the file in a new commit and will ask for the commit message and the destination branch, and run the Pipeline.
If everything is configured correctly the Pipeline will successfully run to completion and you’ll get the delightful green tick mark.
Packaging into NuGet artifacts
And that it for most basic use cases. But in some cases you might want to create a NuGet package and push it to your NuGet repository. In that case you neeed to two additional steps:
- Fetching some NuGet packages from custom NuGet repository
- Packing and pushing the compiled assemblies to the custom NuGet repository.
Creating NuGet feeds
To create a new NuGet feed, you can go to the Azure Artifacts and click on
Then fill in name and permissions and
It is also possible to add some other custom sources to this by going to feed settings and choosing the Upstream sources tab. We can see there are a couple of sources defined already.
Now if you head back to the Pipeline editor, you should be able to choose this feed as NuGet source.
Packing NuGet packages and push them to the artifact repository
For the second task we have to add two new NuGet tasks for packing and pushing the final package to the NuGet feed.
Note that we must configure the versioning based on the company’s policies. For example, here the following versioning policy has been selected which uses date and time policy
Note that if you already have set up the automatic versioning at project level (on the
.csproj ) you can set the Automatic package versioning here to
After a successful pipeline run, the resulting package can be found at the artifacts section.
TestLibrary is the artifact that was created by our NuGet task. You can see that there are two other NuGet packages inside our artifact’s feed and that’s because by default when are are creating an artifact feed, it’s going to add a couple of other Upstream feeds like nuget.org to it.
- Instead of using Microsoft’s clouds, you can run these Pipelines on your own server for free using your own build agent.
- Packages with a pre-release tag will not be shown on NuGet clients by default until the consumer opts-in with a check-box or command line switch.