If you have already some experience with Dynamics 365 for Finance and Operations development, you are most likely familiar with setting up a build system. If not, you should start with the official documentation. In addition to that, you can read my article about setting up a local build VM.

But setting up one build machine is just the beginning. With Azure DevOps build pipelines (previously known as Visual Studio Team Services build definitions) you have full control over the build process. You can also create multiple build processes for different scenarios, so that you can easily work with multiple branches, internal / demo / public releases and so on.

An implementation partner has different requirements than an ISV, and each organization might have their unique needs, so there isn´t one build pipeline approach that would suit everyone. In this article I´m sharing things that I´ve found useful and hopefully it can help others to get more value out of the build options in Azure DevOps.

What is a build pipeline?

A build pipeline is a collection of settings that control the build process. The settings include things like which version control branch should be built, custom PowerShell scripts and triggers (scheduled build or continuous integration / build after every check in). Build pipelines are not unique to Dynamics 365 for Finance and Operations, instead D365FO is utilizing this pre-existing feature of Azure DevOps.

When you deploy a D365FO build machine (topology "Build and Test") from Lifecycle Services, a default build pipeline is created in Azure DevOps. The name of the default build pipeline is "[Your Azure DevOps project name] - Build Main".

Managing build pipelines

You can find existing build pipelines in Azure DevOps by navigating to Pipelines - Builds on the left hand navigation. The default view shows pipelines with recent builds, so if you have just created a new pipeline you need to switch to the Folders view (marked with red in the picture) to see all build pipelines.

If you want to create a new D365FO build pipeline, you should clone an existing pipeline instead of creating a new one from scratch. You can of course edit the existing pipelines, as well as save an existing pipeline as a template.

Important settings

Let´s go through some useful things that you can achieve by adjusting the settings that are available in the build pipeline.

Agent pool

On the main view of the build pipeline edit mode you can change the agent pool of the pipeline. Usually you don´t need to change it. When you are deploying a build environment from Lifecycle Services you can select which agent pool you want to use. One possibility is to use a different agent pool for each D365FO version that you need to build. This way you can for example assign build definitions for D365FO version 8.0 PU 15 for an agent pool that has a build machine with the same version, and have another agent pool and another set of build definitions for 8.1 PU 20.

Branch

You can control which branch is built with these two settings in "Get sources" and "Build solution":

Custom build scripts

You can add your own PowerShell scripts in the build process. These scripts must be placed in the build machine in C:\DynamicsSDK folder. I have written an article that illustrates how to add a script that calculates the number of overlayered objects on each build. Even though that particular script should soon be unnecessary for all D365FO customers (since overlayering is no more possible with the recent version), the instructions apply for including any other script that you might need in your build process.

Variables

In build variables you can control various settings that Microsoft has provided for D365FO builds. For example you can skip deploying the reports ("SkipDeployReports") or the database synchronization ("SkipSyncEngine") if you want to have a fast build for each check in. Then you could have a separate pipeline for the nightly build which is allowed to take more time, and handle the reports and database synchronization only in that pipeline.

If you only need the deployable package, you can use the "SkipSourcePackageGeneration" to skip the generation of the model package. If you have a package for unit tests, you can leave it out from the deployable package with the "PackagingExclusions" variable.

Triggers

You can use the triggers to control when the build should start.

Continuous integration means that the build is triggered after each check in. Gated check in means that the code must be built succesfully before the check in is accepted. Since the D365FO build can take a long time you should consider using the settings described in the Variables chapter to reduce the build time if you want to use these features.

You can also use a traditional scheduled build to build your code daily or nightly.

If your build definition is needed only every now and then, you should not set up any triggers. Instead you can queue the build manually from the build pipelines list.

How many build definitions do I need?

There is not a definite answer to that question. In my own work with an ISV I have found at least the following pipelines very useful:
- Daily or nightly build - the result will be deployed to internal test environment. Since automatic deployment to Microsoft hosted sandbox environment via LCS is not possible at the time of writing, I prefer to build late in the afternoon so that the result can be uploaded to LCS and applied to the test environment at the end of each day.
- Release - This pipeline is used to build the official release packages
- Support - You will obviously need a support branch for all released versions and a build pipeline for each branch.
- Demo - Many ISVs have demo and / or prototype features that need to be handled separately from the actual product code. It makes sense to have a separate pipeline for the demo branch.