在使用我们的TeamCity持续集成服务器时，我们发现了一些我们不确定最佳处理方式的问题。即如何引用我们的应用程序在CI服务器上需要的外部应用程序。在持续集成中，处理外部应用程序依赖关系的最佳方式是什么
这最初是由于依赖于Crystal Reports而发现的，因此我们在服务器上安装了Crystal Reports，解决了即时问题。但是，随着我们将更多的应用程序移动到CI服务器，我们发现更多的依赖关系。
这里最好的策略是什么？是否继续在服务器上安装所需的应用程序？
感谢
尽可能使外部依赖关系成为您的构建系统的一部分。 例如，检查安装程序到您的版本控制系统中，并且有一个步骤将其检出并以静默模式运行（许多安装程序有时使用命令行支持没有用户操作的模式）。
这样，如果您需要为分支机构设置另一台生成机器，或者只是为了新硬件，所有的操作都是可重复的。
如果你使用Maven构建，你可以在pom.xml文件中定义您的依赖。如有必要，他们将自动下载。
我不知道如果我跟着正确...
我假设你的应用程序依赖于这个外部的应用程序，同时建立？在这种情况下，应该在机器上执行CI ...
如果您的构建需要实际的应用程序来完成构建，那么您应该继续在构建服务器上安装该应用程序。
如果您只需要从应用程序中引用dll或程序集，那么我们在我们公司所做的就是创建特定应用程序所需引用的可安装“SDK”，并将它们安装到我们的开发和构建机器上在我们的解决方案参考的着名库目录中。
在构建机器上，我们的构建前步骤会安装正确版本的依赖关系，然后在完成后清理它们。
最近，我们已经开始将虚拟机用于构建过程激活的构建机器。这些虚拟机将SDK作为预生成安装在它们上面，然后在生成后恢复到它们的快照状态。我们有一些几乎不可能卸载的依赖关系，因此每次都有一个干净的起点。