TFS Automated Build Strategy Questions

Question

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 include 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)

score 9 · Accepted Answer · answered Sep 01 '11 at 17:50

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.
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.

score 3 · Answer 2 · answered Sep 01 '11 at 17:50

3

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

answered Sep 01 '11 at 17:50

tsells

2,751
1
18
20

How do you set gated check in on only trunk? (viz your setup) – cpoDesign Nov 21 '11 at 21:55
Google search is your friend.... http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx – tsells Nov 22 '11 at 02:31
That solution is not descriptive enough.. i need it to be for branch...? – cpoDesign Nov 22 '11 at 08:13
Maybe you should ask your question in a new thread to get the responses you are looking for. – tsells Nov 22 '11 at 14:25

score 1 · Answer 3 · answered Sep 01 '11 at 18:12

1

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.

answered Sep 01 '11 at 18:12

scottm

27,829
22
107
159

Thanks for the link, some good info on basic branching approaches. I especially enjoyed the "Branching and Merging Anti-Patterns" section! – Didaxis Sep 01 '11 at 18:27

TFS Automated Build Strategy Questions

3 Answers3