Under the hood of a Gated Checkin

After squashing a few “hey this seems broken” statements after introducing Gated checkins, like most good programmers: I refuse to do anything twice… instead I will automate/document/write a batch file/etc.

Misconception: “Its not associating to any work items or changesets? Something isn’t right…”

Well, of course.  It’s not supposed to.  I naturally had to elaborate on this.

The process of which a Gated checkin takes place is quite simple and putting too much thought into Microsoft’s automagically pipeline will tend to give it the appearance of overcomplexion.

The changeset simply does not exist.  It won’t exist.  That is the sole purpose of the Gated checkin.  It creates a private shelveset automatically based on the developer’s “changeset” it intercepted.  TeamBuild will then queue the shelveset build.

At this point the build workflow begins as normal except one extra step at the beginning… after Getting Sources, it will merge the shelveset and then continue to let MSBuild compile.  At the end of the workflow, there is one final inserted step as well (I’m sure you see where this is going): If successful (compile and/or unit tests) it will merge the shelveset into the repository.

The reconciliation phase then begins…  if it failed, you pull the changes back down and correct it.  If it passed and was merged, you will reconcile your workspace (if you didnt preserve changes on the checkin) and your team members will be notified to reconcile as well (assuming you are using Build Notification via Power Tools).

At the end of this process, if everything passes and the shelveset is accepted, a changeset is finally generated and finally associated to the “now-public” gated build.  It essentially replaces the CI build.

The nightly build will still pickup that changeset and perform associations as well.

Gated Checkin Flowchart