Gated Check-ins are awesome and you should use them!

What is a Gated Check-In? 

A gated check-in is a commit with a condition behind it. Namely, whatever it is you are checking in has to be built in the branch it was committed to as though the commit happened. What is happening behind the scenes is that the commit is being turned into a shelveset with a pending build request for that shelveset. The shelveset will sit until a build agent is available to process it. Once a build is available, it will unshelve the shelveset into the build environment, build it and if it was successful actually commit the shelveset to the branch as a "full" commit. If the build fails, the shelveset remains so you can recall it and correct any issues if they exist. Depending on how you want to manage this, you can commit your pending changes in your development branch, you will get a notice that it must be built first. You can wait for the build to complete or undo your pending changes. If the build completes, do a get latest and now you have whatever you committed with the gated check-in. If it fails, you can recall the shelveset, fix it then try again.

Why is this Useful?

In Fin and Ops, this can help prevent problems with your merges breaking a build because dependencies aren't met or a developer forgot to source control an element or many other reasons. This is just a great check to prevent problems from progressing to a commit. This won't prevent bad code - just code that won't compile. Also, for later branches, this can help prevent "bad" changesets from making it into a branch without being vetted as a compile level first. A manual merge may introduce some bad XML which a build would call out. 

When Would This Ever Happen?

More than you'd think. Here is a perfect example of how to break a build.

• Create a new model with a new package (VS > Dynamics 365 > Model Management > Create Model...)
• Name it whatever you would like
• Select any reference package that is a form adaptor, like "RetailFormAdaptor"
• Create it
• Add the package to source control
• Commit it

Potentially unknown to you, form adaptors are no longer on a non-developer machine so those simple acts are enough to break your build for Trunk once you merge that changeset.

Can I Prevent This?

Yes! enter gated check-ins. If you had gated check-ins setup on this dev branch, let's call it dev2, the changes would have been submitted to your build box before Azure DevOps would accept the commit. 

Let's Set It Up!

It's fairly easy. We'll assume that you have a build definition already setup. If not, clone your trunk or release defintion and change the sources to point to your developer branch. Once you have that setup, its just a simple checkbox to turn it on.

Just check that, commit something and watch what happens!