我们正在简化/自动化构建，集成和单元测试以及部署。 我们的软件是在Visual Studio中开发的，我们在项目中使用C＃和VB.NET。单个项目可以包含在多个解决方案中（即，在ProductA和ProductB解决方案中都使用了Utils项目）
由于历史原因，我们的代码存储库的结构不如人们所希望的那么好。 例如。 Utils项目可能位于ProductA解决方案下（因为它是第一次使用的）但后来被认为对productB开发有用，并且仅仅包含在productB的解决方案中（但仍位于productA的子目录中）。
我想使用连续集成测试并设置CC.NET构建服务器，我打算使用NAnt来创建实际构建。
问题1：我应该如何在构建服务器上构建构建？我是否应该指示CC.NET将productB的所有项目检索到单个库中，例如类似于
的文件结构-ProductB
--Utils
--BetterUtils
--Data
或者我应该选择与此类似的文件结构
-ProductA
--Utils
-ProductB
--BetterUtils
--Data
然后让NAnt构建脚本处理引用？我们在VS中的引用与代码库中的实际位置不匹配，所以今天不可能只是检查出productB解决方案并立即构建它（不幸的是）。我希望这个问题有道理吗？
问题2：最好将位于不同项目中的所有源代码检出到一个文件夹中（同时保留某种结构），然后一次构建所有内容或具有多个在CC.NET中的项目，然后让CC.NET服务器处理依赖项？ 例： 我是否应该在CC.NET中有一个单独的项目来监控Utils项目的自动构建/测试，当它从未在它自己发布时？或者我应该在构建它作为ProductB的一部分时构建/测试它吗？
我希望上述内容有意义，并且您可以为我提供使用任一选项的一些参数。我们远不是一个理想的源代码存储库结构，如果我可以解决构建服务器上缺少存储库结构而不必清理我们的存储库结构，我更愿意。 不幸的是，切换远离VSS是一种选择。
现在我们的构建包括通过VS clickonce部署或按F5，这样只需让构建自动化对我们来说是一个巨大的进步。
谢谢
答案 0 :(得分：0)
要回答您的第一个问题，我建议为每个构建项目使用单独的顶级文件夹。使单个树与源存储库匹配的问题是，当您的构建服务器尝试一次运行多个构建时，由于其他进程正在使用的文件，一个或多个树可能会失败。此外，您可能会遇到构建脚本正在提取旧版本代码的情况。在那种情况下，您不希望不同的项目意外使用不正确的源版本。
如果您的解决方案已经从相对路径引用项目，那么最终可能会得到如下结构：
-CCNetBuilds
--ProductASource
---Utils
---...
--ProductBSource
---ProductA
----Utils
---ProductB
----BetterUtils
----Data
在这种情况下，产品B的构建包含产品A源的一部分，与解决方案预期的路径相同。这需要花费更多的时间在CC.Net中进行设置，但如果开发人员在他们的计算机上以这种方式设置代码，则可以更容易维护。构建服务器使用开发中使用的相同解决方案文件。
要回答你的第二个问题，我更喜欢Utilities是自己的构建。如果我在我的Utilities组件上进行单元测试，我不希望它们针对使用Utilities的每个产品运行。此外，如果您具有针对Utilities的单独构建，则可以在CC.Net中设置依赖关系，以便在Utilities构建中断时，产品A和B不会尝试构建。这提供了一些更快的反馈意见。