在持续集成中，处理外部应用程序依赖性的最佳方法是什么

题

在使用我们的TeamCity持续集成服务器时，我们发现了一些我们不确定最佳处理方式的问题。即如何在CI服务器上引用我们的应用程序所需的外部应用程序。

最初发现这是依赖于Crystal Reports，因此我们在服务器上安装了Crystal Reports来修复即时问题。但是，当我们将更多应用程序移动到CI服务器时，我们发现了更多依赖项。

这里最好的策略是什么？是否继续在服务器上安装所需的应用程序？

由于

解决方案

尽可能使外部依赖项成为构建系统的一部分。例如，检查安装程序到您的版本控制系统，并有一个检查它的步骤并以静默模式运行它（许多安装程序支持一种模式，有时使用命令行没有用户操作）。

这种方式如果您需要为分支机构设置另一台构建机器或仅为新硬件设置，则一切都是可重复的。

其他提示

如果您的构建需要实际的应用程序来完成构建，那么您应该继续在构建服务器上安装该应用程序。

如果您只需要从应用程序引用dll或程序集，那么我们在公司所做的就是创建可安装的“SDK”，其中包含特定应用程序所需的引用，并将它们安装在我们的开发和构建机器中我们的解决方案参考的着名库目录。

在构建机器上，我们的预构建步骤会安装正确版本的依赖项，然后在完成后进行清理。

最近，我们已经开始使用虚拟机来构建我们的构建过程激活的构建机器。这些虚拟机将SDK作为预构建安装在它们上，然后在构建后恢复到其快照状态。我们有一些几乎不可能卸载的依赖项，所以每次都有一个干净的起点。

如果使用Maven进行构建，则可以在pom.xml文件中定义依赖项。如有必要，它们将自动下载。

我不确定我是否正确遵循......

我假设您的应用程序依赖于此外部应用程序，同时构建？在那种情况下，它应该在机器上做CI ......

许可以下： CC-BY-SA 和归因