构建服务器上的 NAnt 构建脚本和解决方案结构的结构

Question

我们正在简化/自动化构建、集成和单元测试以及部署。 我们的软件是在 Visual Studio 中开发的，我们在项目中同时使用了 C# 和 VB.NET。单个项目可以包含在多个解决方案中（即 Utils 项目同时用于 ProductA 和 ProductB 解决方案）

由于历史原因，我们的代码存储库的结构不如人们希望的那样好。 例如。 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 进行部署，所以让构建自动化对我们来说是一个巨大的进步。

谢谢

Answer 1

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

如果您的解决方案已经从相对路径引用项目，您最终可能会得到这样的结构：

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

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

为了回答您的第二个问题，我更喜欢 Utilities 是它自己的构建。如果我对我的 Utilities 程序集进行单元测试，我不希望它们对使用 Utilities 的每个产品都运行。另外，如果你有一个单独的 Utilities 构建，你可以在 CC.Net 中设置一个依赖，这样如果 Utilities 构建被破坏，产品 A 和 B 就不会尝试构建。这样可以更快地反馈出现问题。