Question

我的机器上安装了NUnit“C：\ Program Files \ NUnit 2.4.8 \”，但在我的集成服务器上运行（运行CruiseControl.Net）我将它安装在“D：\ Program Files \ NUnit 2.4”中。 8 \”。问题是在我的开发机器上我的NAnt构建文件正常工作，因为在任务中我使用路径“C：\ Program Files \ NUnit 2.4.8 \ bin \ NUnit.Framework.dll”来添加对'的引用NUnit.Framework.dll'程序集，但是这个相同的构建文件无法在我的集成服务器上构建文件（因为引用路径不同）。我是否必须将NUnit安装在与集成服务器相同的位置？这个解决方案似乎对我来说太严格了。还有更好的吗？这类问题的一般解决方案是什么？

Answer 1

通常我会将NUnit和任何其他依赖项与我的项目一起分发到某个公共位置（对我来说，这是顶层的 libs 目录）。

/MyApp
  /libs
    /NUnit
    /NAnt
    /etc...
  /src
    /etc...

然后我只是从我的应用程序中引用这些库，它们总是位于相对于项目解决方案的相同位置。

Answer 2

通常，应避免对绝对路径的依赖性。就CI而言，您应该能够使用源代码控制中的资源通过自动脚本完全从scatch在干净的机器上构建和运行您的解决方案。

Answer 3

“终极”解决方案可以将整个工具链存储在源代码控制中，并存储您在源代码控制中构建的任何库/二进制文件。设置正确，这可以确保您能够从任何时间点完全按照发货时重建任何版本，但此外，您不需要这样做，因为您生成的每个二进制文件都是源控制。

然而，达到这一点是一项严肃的工作。

Answer 4

我使用两种方法：

1）使用具有不同路径的两个不同的临时脚本（dev build / integration build）。

2）将所有需要的可执行文件放在您的路径文件夹中并直接调用它们。

Answer 5

我同意绝对的道路是邪恶的。如果你无法绕过它们，你至少可以在脚本中设置NUNIT_HOME属性，默认为C：...并在CI服务器中调用脚本，在命令行传入NUNIT_HOME属性。

或者您可以将脚本设置为要求设置NUNIT_HOME环境变量以使NUNIT正常工作。现在，您的脚本要求nunit存在并且在环境变量中可用，而不是要求它运行的机器具有nUnit。

这两种方法都允许您在不修改构建脚本的情况下更改正在使用的nunit版本，这是您想要的吗？

Answer 6

在版本控制下使工具链中的所有工具都是一个很好的想法。但是在您的路径上，您可以使用几种不同的技术来指定每台机器的不同路径。

NAnt让你define a <property>可以用-Dname=value覆盖。您可以使用它来为您在CI系统中覆盖的开发机器设置默认位置。

您还可以使用environment::get-variable获取环境变量的值以更改每台计算机的位置。

如何弥补开发机器和构建服务器之间的环境差异？

6 个答案: