如何管理构建服务器上自动构建的依赖项？

Question

我正在尝试将持续集成实施到我们的日常工作中。在我们的团队中，我们正在从仅在工作站上的 Visual Studio 中构建代码并进行部署，转变为使用 MSBuild.exe 并在我们的构建服务器（即 Jenkins）上自动化，而不使用 Visual Studio。

我们对项目中的 Automap 等引用有外部依赖。因为 automap（例如）dll 不在构建服务器上，msbuild 执行失败，原因很明显。还有其他 dll 我需要成为构建的一部分，我只是以 automap 为例。

那么，作为自动构建的一部分，将任何依赖项添加到构建服务器上的最佳方法是什么？我已经看到使用“lib”文件夹的引用，但我真的不明白我应该把它放在哪里（在我的项目、文件系统、SVN 中……？），以及构建服务器将如何到达它。我还读到 NuGet 可以做一些依赖项的事情，但我的构建服务器没有连接到互联网，我不明白如何让我的构建来提取我可能创建的 NuGet 包，以及它是如何实现的一起工作。

编辑：我正在使用 subversion，我们不能使用 TeamCity，因为我们必须购买它，而且获得资金的机会为零。

Answer 1

我们运行 SVN + CCNet。我们有一个用于 3rd 方库的 SVN 存储库，如下所示：

/foo/foo-1.2.3
/foo/foo-1.4.0
/bar/bar-1.0.0

也就是说，每个库都有一个目录，每个可用版本都有子目录。

一条规则是目录必须包含原始库 - 即您解压缩并提交，不允许修改。

当您的项目中需要一个库时，您可以添加一个 lib 目录并用链接 (svn:externals) 填充它到来自 3rd 方存储库的库。重要的是，您不要在本地目录名称中包含版本号。如果您需要 foo-1.4.0，则 lib 目录中的 svn:externals 链接将如下所示：

foo https://svn-server/3rdparty/foo/foo-1.4.0

即它最终在/lib/foo 中。这样升级版本就变得容易多了，因为您所要做的就是更改 svn:externals 链接以指向新版本，并且（只要文件名没有更改）所有项目都会自动获取并进行编译.

至于 NuGet .. 比它的价值更多的麻烦，但意见不同:)

希望有帮助

Answer 2

我喜欢 stmax 的解决方案，但此时对您来说可能有点太多工作。

最简单的做法是在您的存储库中创建一个 lib 目录，并将所有第三方程序集添加到该目录中。 更新所有项目以从此 lib 目录中引用第三方程序集。检查所有内容。当构建服务器唤醒进行下一次构建时，它将拉取最新的更改，其中将包括新的 lib 目录和项目引用更改。绿色建筑！