构建服务器/CI设置-使用应用程序中的最新组件

解决这个问题有两种方法:

1-您依赖的组件是否独立并在任何地方重复使用?
或
2-这是一个大型系统的一部分,它相互依赖,但很好地模块化到不同的项目中。

我不完全确定在第一个场景中最佳实践是什么,但我可以解释在第二个场景中我做了什么。

假设你有以下结构

躯干
主干/罗盘
/trunk/rob.mycoolapplication.server(中继/rob.mycoolapplication.server)
/trunk/ron.mycoolapplication.client(中继/ron.mycoolapplication.client)

每一个都是“顶级”应用程序,每个都有自己的解决方案和目标,它们独立编译,但它们是同一个系统的一部分。

为了以最少的麻烦实现“平滑”的构建集成,我始终建议尝试在开发和构建服务器上重现相同的环境。因此,当您签出以编辑这些应用程序时,应该签出/trunk-into/mytrunkfolder。

现在,我倾向于在任何可重用的.dll或组件上执行生成后操作,设置一个生成后操作,将其生成输出(在发布模式下)xcopy到:

/Trunk/CompiledOutputs/ApporLibName/

重要的是永远不要签入此文件夹,它应该通过构建必要的解决方案来生成。

现在,在rob.mycolapplication.server中向rob.core添加引用时,实际上添加了对/trunk/compiledOutputs/rob.core/some.dll的引用。

这样,您的开发环境看起来就像您的构建服务器。 一旦正确连接了依赖项,就需要在CI系统中添加触发器。在ccnet中,对于上面的示例,我将在rob.core的成功构建上放置一个触发器,以触发rob.mycoolapplication.server的构建。

当您重新签出系统时,建议使用一个批处理脚本来触发依赖关系中的msbuild以构建环境。

只有当您总是希望根据组件的最新版本构建应用程序时,上面的内容才有效。如果不是这样的话,您可能希望将引用程序集的签入文件夹作为使用它们的应用程序的一部分,然后在有效时手动更新到编译组件的新版本。

关于这个主题的文章很少,所以大部分都是在3-4个项目中摸索出来并推断出来的,但在我最后的两个大型项目中,它肯定是可重复和可靠的。显然,和以往一样,你的里程数可能会有所不同。

几乎所有的.NET构建服务器都在解决方案之外工作,以获取项目引用/依赖关系。要考虑的主要问题是构建路径必须镜像您的开发人员路径。

现在,要清楚,如果您使用的是GAC的程序集,那么这些程序集也必须是您的构建服务器上的GAC。否则会遇到问题。

举个例子,您的解决方案文件中应该同时包含项目A和项目B。此外,对于A来说,应该存在对B的项目依赖关系。您可以通过右键单击项目B中的“引用”文件夹,选择“项目”选项卡,然后选择“项目A”来实现这一点。

这个信息存储在项目B中。解决方案维护了B的引用和项目A之间的链接。我希望这是有意义的。

Ant 和 nAnt 是Java和.NET的两个构建工具,它们可以帮助脚本。 Msbuild 或 Cruise Control 如果你想要更多的想法,可能也是有用的工具。

我可能会使用一些脚本,在构建B时说必须首先构建A,这是大多数现代构建工具支持的依赖关系。