Automated Build Management

In this chapter, we will cover the steps that are required to set up and use a build server. We touched upon some of the benefits of a build server in Chapter 12, Unit Testing, where unit tests can be executed to help reduce the risk of regression.

We shall cover two scenarios: a cloud-hosted customer implementation project deployed via LCS, and an on-premise build server, which is equivalent to an Azure server hosted under your own subscription.

If the implementation is hosted in Azure and is deployed through an LCS customer implementation project, all we need to do is set up Build Agent Pools and then supply parameters to the setup form in LCS. The process of deploying a build machine is well documented and we won't duplicate this here, especially given the pace at which updates to LCS are being made. Even if we don't set up a build server...

Technical requirements

You can find the code files for this chapter on GitHub at https://github.com/PacktPublishing/Extending-Microsoft-Dynamics-365-Finance-and-Supply-Chain-Management-Cookbook-Second-Edition

Creating a Team Services Build Agent Pool

Agent Pools contain Build agents; in SCM build server configurations, we have one Build agent for each Agent Pool and only one Agent Pool in the Azure DevOps project. Build agents act as a bridge between Azure DevOps and the physical build server. The build agent is created when we configure the build server, and that process needs to have an Agent Pool already created.

When build servers are provisioned from LCS, we will have a one-to-one relationship for this. This is because a project will typically have its own build server (which is not limited to one), and keeping queues and pools with a one-to-one relationship simplifies management.

Getting ready

You will need to have created...

Setting up a build server

The build server is a one-box Dynamics 365 for Operations virtual machine, usually with demo data that is only ever used to produce builds. Even though it contains data and seems to have an application running in IIS, it cannot be used.

If we are creating a build server for a customer implementation project, most of the work will have been done for us already. We just need to specify the Agent Pool that we created in the previous recipe. This recipe will follow the ISV scenario where we install the build agent ourselves.

Getting ready

You will need a build server VM running with access to the internet, and the Agent Pool created against the project.

...

Managing build operations

This recipe focuses on what happens when a build is triggered, and how to deal with some common issues. We will trigger a build and then monitor its progress.

Getting ready

We must have a fully functional build server and a build definition that will trigger on check-in. To reiterate the point we made at this start of this chapter, all changes must only be made on development machines, and never on the build server. Even though Visual Studio might be installed on the build server, it should never be used.

How to do it...

To manage build operations...

Releasing a build to User Acceptance Testing

At the end of the build process, a deployable package file was uploaded to the build. This file can then be applied to your user acceptance test or sandbox server.

We can apply the package manually on the test server but, for LCS-deployed User Acceptance Testing (UAT) environments, this is always done via LCS. Any release to production must be deployed to a sandbox server first and marked as a release candidate.

A simplified process for the release to UAT would involve the following steps:

1. The development team writes code and completes the tasks that are required for the next build (for example, those that are assigned to the current sprint).
2. The developers will also write unit tests and perform their own unit tests.
3. Initial testing will be done by taking a package from the Dev branch pipeline and deploying it to a OneBox. This is...