TFS 2010: Gated Check-In On Main Branch; Rolling Builds on Dev Branch?

Question

I recently migrated from VSS to TFS 2010 and I've been absolutely loving it, but there's something I haven't yet been able to get working the way I think it should.

GOALS

I'd like to quickly know when a change to Development breaks a build. If we find out after-the-fact, it's no big deal. Since a lot of check-ins happen throughout the day, we don't want to wait on the build to finish, so it should be asynchronous.

With our Main branch, I'd like to ensure that any time a merge happens into it, we make sure it's not going to break the build. I want immediate feedback on this. The wait time is fine, since we won't be merging into Main often.

CURRENT SETUP

My solution is under a folder called Main. I've made a branch off of that called Development. The workspace I'm working in is tied to the top-level, which includes both Main and Development branches. I tried adjusting my workspace to only point to Development, in case that was the problem. That didn't seem to fix my issue, so I set it back to the way I had it originally -- with both Main and Development.

Within the workspace's Build definitions, I have two definitions defined -- one for the Main branch and another for Development.

The first definition is for building the Main branch. It has a Gated Check-In trigger and "Items to Build" points to the solution file within Main.

The second definition is for building the solution in the Development branch. It has a Rolling Builds trigger and "Items to Build" points to the solution file within Development.

RESULT

Currently, when a change is made in Development and a check-in is performed, the gated check-in to Main is triggered. This not only causes confusion, but it also tends to slow down our overall process.

NEXT STEP

I've looked at some of the TFS guides to branching, general TFS usage, etc. Unfortunately, I haven't yet found a solution to my issue. If you've run across this issue before, I'd appreciate any suggestions you can give.

Answer 1

I'm not 100% sure at the moment, but the build should be triggered by check-ins into the part of the source tree that is covered by the build definition workspace.

So please have a look into the build definition and see what part of the source tree each build definition gets. Your CI build should only get the Dev branch, the gated build should only get the Main branch.