【问题标题】:How do I manage dependencies for automated builds on my build server?如何管理构建服务器上自动构建的依赖项?
【发布时间】:2012-06-13 04:30:56
【问题描述】:

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

在我们的项目中,我们对引用(例如 Automap)有外部依赖关系。因为自动映射(例如)dll 不在构建服务器上,所以 msbuild 执行失败,原因很明显。还有其他 dll 需要我参与构建,我只是使用 automap 作为示例。

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

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

【问题讨论】:

标签: .net build msbuild continuous-integration dependency-management


【解决方案1】:

我喜欢 stmax 的解决方案,但目前对您来说可能工作量太大了。

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

【讨论】:

  • 我是否更新我的引用以直接从存储库本身获取第三方程序集(这甚至可能吗?),或者在我检查后从我的开发工作站上的工作副本中的 lib 文件夹出去?如果是前者,我需要为此使用 svn:externals 吗?
  • @TomPickles 您更新它们以引用工作副本中 lib 文件夹中的程序集。 Visual Studio 使用相对路径进行引用,因此它们将在检出存储库的每台机器上工作。
【解决方案2】:

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

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

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

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

当您在项目中需要一个库时,您可以添加一个 lib 目录并在其中填充指向 3rd 方存储库中的库的链接 (svn:externals)。这里重要的是您不要在本地目录名称中包含版本号。如果你需要 foo-1.4.0,你的 lib 目录上的 svn:externals 链接应该是这样的:

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

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

至于 NuGet.. 麻烦多于其价值,但意见不同 :)

希望有帮助

【讨论】:

  • +1 这几乎就是我们管理 3rd 方库的方式。唯一的区别是我们称它为 Externals 而不是 Lib。 ;)
  • Stmax,除了你所说的,我过去还有一个名为 /foo/Latest 的附加文件夹,它指向其他文件夹之一,例如/foo/foo-1.6.0.这允许通过控制文件夹的内容来更新引用。然后,您可以进行一些控制,以便当多个项目/团队不与多个版本的 dll 发生冲突时。
【解决方案3】:

您应该详细阅读 NuGet,因为它允许您设置内部包存储库,

http://weblogs.asp.net/jgalloway/archive/2011/02/02/downloading-a-local-nuget-repository-with-powershell.aspx

【讨论】:

    【解决方案4】:

    无论您的系统有多优雅,您的首要目标都应该是运行 CI。在构建系统时,“lib 目录”选项通常是最简单的。您将二进制文件检入 Subversion。这很丑,但它可以让你开始,你的构建级别将是可重现的,这是必须的。完成此操作后,研究并选择适合您需求的外部依赖版本控制系统(可能是 Nuget)。

    附带说明,请仔细检查 TeamCity 的免费部署是否不适合您。上次我检查了您必须拥有大量协调项目或大量构建代理才能要求许可证。

    【讨论】:

      猜你喜欢
      • 2010-09-06
      • 2016-03-24
      • 2018-01-29
      • 2017-11-18
      • 2014-11-19
      • 2012-03-09
      • 2012-01-15
      • 1970-01-01
      • 2017-02-12
      相关资源
      最近更新 更多