Getting started with Gated check-ins is easy.

Getting Started

Once you have created a build environment, this will check-in a few files. We're interested in the AXModulesBuild.proj file. We'll want this file to be in the root of all branches, on the off change we need to change it for that specific branch. This is rare but we can plan ahead just in case. Below is an example of where to place the file and an example branching structure.

Next, We'll need to create a projects.xml file in the projects directory for each branch, if we don't have one already. It will look similar to this:

<?xml version="1.0" encoding="utf-8"?>
<Projects xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Project>
    <Type>Metadata</Type>
    <Name>AAXWarehouseDimensionLink</Name>
  </Project>
</Projects>

like so:

Branching

Setting up your code branches is important and its crucial that you have a plan before you get started. Here are two examples:

Exhibit A

Exhibit B

Xzibit

Exhibit A is an example of each developer having their own branch. Each branch would need to have a gated check-in definition for each and all changesets would need to be merged from each dev branch to DevRelease as well as periodic "back merges" from DevRelease to each dev branch. This can be advantageous when each developer is working on major features that have no dependencies on what others may be working on. However, there is a fair amount of technical management to make sure all of the code is where it should be. In AX 2012, this structure made lots of sense but in D365 it is less advantageous and represents and older style of working.

Exhibit B is an example of 1 developer branch, 1 trunk with no devRelease branch and a release branch. This is more inline with modern practices as all developers will be working against the same workspace. With gated check-ins setup, no one should be able to break a model or package as their changes will be shelved, built and committed if that shelveset passes the quality bar set (ie, compile or compile and test). However, gated check-ins are critical for this to work as gated check-ins are the mechanism that prevents garbage from being accepted. Depending on the volume of check-ins, you may have to spin up additional build VMs but that would be rare. 

The gated check-in definition in Azure DevOps may be different for each branch. As a for instance, in Dev related check-in definitions, I typically do not deploy reports. However, I will do this in trunk and release branches. 

Creating A Pipeline Definition

We'll assume you already have a build pipeline definition from the creation of your build machine called "Main". 

• Go to pipelines, click on ΓÇ£Unified Operations platform ΓÇô Build MainΓÇ¥, click on the 3 dots in the upper left-hand corner then select clone.
• Select the cloned pipeline, click edit and give it a name for the branch you will be building; ie, Release.
• Select ΓÇ£get sourcesΓÇ¥
• Change the server path to be the path for the branch you want to build
• click on the Triggers tab and select "enabled gated check-in".

• Next, disable the tasks that you don't want to run, such as deploy reports

Here are some screens from one of my dev build configurations