TFS Automated Build Strategy Questions

I'm new to Team Foundation Server, and I'm currently working on setting up an automated build strategy for my project. One bit of confusion I'm having is how to setup automated builds that match our source control/development structure.

It is company policy that under a TFS project, we includ开发者_如何学Goe the folders 'trunk' and 'branches'. 'Trunk' represents and contains our production code. 'Branches' obviously holds branches under development.

I'd like to setup CI (continuous integration) builds for branches, and a 'Gated check-in' build for 'trunk'. My thinking is that this will virtually eliminate any problems with 'trunk' builds when it's time to roll-out to production. I do however have a few questions about all of this:

1. Does my strategy make sense? (Is it too redundant? Does it create unforeseen issues? etc.)

2. Does a 'merge' constitute a 'check-in' that will a trigger a CI or Gated build? If developers will merge their development branches into 'trunk', I'd like this to trigger the trunk build. (Perhaps a 'Gated' build here is an unnecessary redundancy?)

Any guidance you can give me is most appreciated. Thank you in advance!

(Development environment: TFS 2010, VS 2010 Ultimate, Windows Server 2008 R2)

1. I think so. We do the same thing with a lot of success. The gated builds can be kind of wonky for every day development as there is constant merging going on after builds but from a branch-to-branch merging standpoint, you won't have too many issues. Keep in mind, when you check in a unmergable binary file during a check-in you cannot preserve your changes locally, when a gated build is enabled.

2. Yes. Merging happens locally and then you check in the merged files. This will trigger whatever build you have setup for that branch.

I have found that these strategies keep the code base pretty put together. I have run into issues where gated builds just aren't practical because it becomes very difficult to correct certain issues. I've had to resort to turning off the gated to get certain changes "merged" in and then re-enabling it afterwards.

Any source control check in (including merge) will trigger a source control change event and have a changeset associated with it.

Our normal setup

Project 
Project\trunk
Project\branches
Project\releases

I do something similar and set the workspace directory in the build configuration as localized as I need it. Having a Gated check-in on trunk ensures that you always have successfully building code in your trunk branch, so I don't think it's too redundant.

This link has a bunch of information that helped me with establishing a merge strategy.