结构建设构建服务器

Question

我们在简化/自动化构建，集成和单元测试以及部署的过程中对脚本和解决方案的结构。 我们的软件是在Visual Studio中开发的，我们在项目中使用了C＃和VB.NET。单个项目可以包含多个解决方案中（即utils的项目在这两个产品A和产品B解决方案中使用）

由于历史的原因，我们的代码库是不是也构成为一个可以期待的。 例如Utils项目可能位于ProductA解决方案下（因为它是第一次使用的），但后来被认为对productB开发很有用，并且仅仅包含在productB的解决方案中（但仍位于productA的子目录中）。

我想用连续集成测试和已经安装在那里我打算使用楠创建实际建立一个CC.NET构建服务器。

问题1：我应该如何构建buildserver上的构建？我应该指示CC.NET将productB的所有项目都检索到单个库中，例如类似

-ProductB 
--Utils 
--BetterUtils 
--Data 

，或者我应该选择一个filestructure类似这样

-ProductA 
--Utils 

-ProductB 
--BetterUtils 
--Data 

，然后文件结构才有南特构建脚本处理的参考？我们在VS中的引用与代码存储库中的实际位置不匹配，因此今天不可能仅检出productB解决方案并立即构建它（不幸的是）。我希望这个问题有意义吗？

问题2：是更好地在一次检查位于不同的项目到一个文件夹中的所有源代码（同时保留某种结构），然后建立每一件事，或者在CC多个项目。 NET，然后让CC.NET服务器处理依赖关系？ 例子： 我应该在CC.NET监测utils的项目的自动化构建/测试时，它从来没有它自己发布了一个单独的项目呢？还是应该在构建ProductB的同时构建/测试它？

希望以上有意义，你能为我提供一些参数，使用任一选项。我们远不是一个理想的源代码存储库结构，我更喜欢是否可以解决构建服务器上缺乏存储库结构而不必清理存储库结构的问题。 切换离开VSS（不幸的是）不是一个选项。

现在我们的构建包括通过VS的ClickOnce部署两种或按F5所以刚开始的自动化将是我们一个巨大的一步，构建。

感谢

Answer 1

要回答你的第一个问题，我会建议一个单独的顶层文件夹的每个构建项目。使单个树与源资源库相匹配的问题是，当您的构建服务器试图一次运行多个构建时，由于其他进程正在使用的文件，一个或多个构建可能会失败。此外，您可能会遇到构建脚本正在拉动旧版代码的情况。在这种情况下，您不希望另一个项目意外地使用不正确的源版本。

如果您的解决方案已经参考项目从相对路径，你最终可能会像这样的结构：

-CCNetBuilds 
--ProductASource 
---Utils 
---... 
--ProductBSource 
---ProductA 
----Utils 
---ProductB 
----BetterUtils 
----Data 

在这种情况下，建立产品B包含了产品的部分源，在与您的解决方案所期望的相同的相对路径。这需要更多时间在CC.Net中进行设置，但如果开发人员在机器上以这种方式设置了代码，则可以更容易地进行维护。构建服务器使用开发中使用的相同解决方案文件。

要回答你的第二个问题，我更喜欢Utilities是它自己的版本。如果我对我的Utilities程序集进行了单元测试，我不希望它们针对使用Utilities的每个产品运行。此外，如果您有单独的实用程序构建，则可以在CC.Net中设置依赖关系，以便产品A和B在公用程序构建损坏时不会尝试构建。这提供了一些更快的反馈，即某些事情是错误的。