The Gated Check-in builds help teams prevent broken builds by not automatically committing pending changes to the repository, but the system will instead create a separate shelveset that will be picked up by the Gated Check-in Build. The build itself will finally decide if the pending changes need to be committed to the repository based on the applied quality gates. In large teams, the main branch is normally gated and DEV/ feature branches are gate to offer more protection for the branch.
A gated check-in means that a build is performed with one set of changes from one developer and if that passes those changes are checked-in. This means that breaking changes never get it into the code base and it limits the pain to the developer checking-in rather than sharing that pain with the entire team when somebody makes a mistake.
Setting up a gated check in
- In Team Explorer, make sure you are connected to the team project and then open the Builds page.
- Choose the New Build Definition link or select a build, open its shortcut menu
- Choose Edit Build Definition.
- On the Trigger tab: Choose Gated Check-in.
When a user check-ins some code, Visual studio prompts for validating the build.
On selecting the Build Changes option, the team explorer window shows the status of build validation.
On successful build, TFS prompts the user the status of the check-in
Clicking the “Reconcile …” button will force an undo in the local workspace and pull the changes that were committed by the Gated Check-in build