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 服务器处理依赖关系？ 例子： 当 Utils 项目从未单独发布时，我是否应该在 CC.NET 中有一个单独的项目来监视 Utils 项目的自动构建/测试？或者我应该在将其构建为 ProductB 的一部分的同时构建/测试它？

我希望上述内容有意义，并且您可以为我提供一些使用任一选项的论据。我们离理想的源代码存储库结构还很远，我更希望能够解决构建服务器上存储库结构缺乏的问题，而不必清理存储库的结构。 （不幸的是）放弃 VSS 不是一个选择。

现在，我们的构建包括通过 VS clickonce 进行部署或按 F5，因此自动化构建对我们来说将是一个巨大的进步。

谢谢

Answer 1

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

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

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

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

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