开发者

Organizing Multi-Solution Builds

开发者 https://www.devze.com 2023-02-09 13:12 出处:网络
We are mov开发者_开发问答ing to TFS 2010 from SVN/CruiseControl .NET and I am trying to get my head around how to set up automated builds for the following scenario.

We are mov开发者_开发问答ing to TFS 2010 from SVN/CruiseControl .NET and I am trying to get my head around how to set up automated builds for the following scenario.

Assume a large codebase that contains several solutions, that in turn reference a large number of projects:

Organizing Multi-Solution Builds

So, in this example Solution 1 references Project A, Project B, Project C and Project D. Solution 2 references Project C and Project E.

What is the best way of organizing this type of setup within TFS 2010 when using TFS as a build system. Specifically, we want to avoid TFS building Solution 1 when only Project E has been modified, but conversely we would want both Solution 1 and Solution 2 to build when Project C has been modified.

Any good documentation or ideas that anyone can suggest?


This is super easy to do in TFS. This will be done almost automatically for you.

When you create a build, you indicate what the "Workspace" is. This is the folders in TFS that contain code for the build. The build triggers are only fired when a file is checked into a folder that is listed in the "Workspace" section.

Organizing Multi-Solution Builds

So you would make two builds:

  • One for Solution1 that has a workspace setup with the folders that contain Projects A, B, C and D.
  • The second build would be for Solution2. Its workspace would have the folders for Projects C and E.

If you set these projects to trigger with the "Continuous Integration" option then you are going to get just what you are looking for. (Solutions 1 & 2 will build when Project C is changed, Only Solution2 will build when E is changed and Solution1 will build when Project A, B or D is changed).


Reconsider using Teambuild/TFS. Not what you want to hear i know... You could have supported this easier with svn and check in shared built dlls.

If the builds use the same workspace you could set the second to build and not rebuild? that way it would compile much quicker and make sure the source triggers exclude the relevant projects.

I can see why you dont what to use cruise control .net anymore but you could use teamcity which is much nicer. Good luck

0

精彩评论

暂无评论...
验证码 换一张
取 消