views:

73

answers:

1

Hey all, here is the issue I am currently trying to work through. We are using Team Foundation Server 2008, and utilizing the automated build support out of the box.

We have one very large project that encompasses a number of interrelated components and web sites, each of which is set up as a Visual Studio solution file.

Many of these solutions are highly interrelated since they may contain applications, or contain common libraries or shared components. We have roughly 20 or so applications, three large web sites, and about 20 components.

Each solution may include projects from other solutions. For example, a solution for a console app would also include the project files for all of the components it utilizes, since we need to ensure that when someone changes a component and rebuilds it, it is reflected in all of the projects that consume that component, and we can make sure nothing was broken.

We have build projects for each solution, whether that's an application, component, or web site.

For this example, we will call them solutions 01, 02, and 03. These reference multiple projects (both their own core project and test projects, plus the projects relating to various components).

Solution 01 has projects A, B, and C.

Solution 02 has projects C, D, and E.

Solution 03 has projects E, F, and G.

Now, for the problem.

If I modify project A, the system will end up rebuilding all three solutions.

Worse, all thirty solutions reference common projects used for data access (let's call it project H). Because they all share one project in common, if I modify any solution in my stack, even if it does not touch project H, I still end up kicking off every single build script.

Any thoughts on how to address this? Ideally I would only want to kick off builds where their constituant projects were directly modified - i.e in the example below, if I modified project C, I would only rebuild solutions 01 and 02.

Thanks!

+1  A: 

Was able to figure this out by limiting the scope of the workspaces in my build definitions per this excellent article by Martin Woodward:

TFS Top Tip #16 - Limit What you Build

Bob Palmer