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
No comments:
Post a Comment