我正在使用Jenkins，Gradle和Artifactory对新构建系统进行原型设计。在指定构建工件及其目标方面，这些工具中似乎存在冲突或相当重叠的特征。我看到了前进的三条道路：
我看到所有这些方法的专家和骗子，但据我所知，我们的构建中没有任何内容缺少关键功能。
为了让我更加困惑，Gradle Artifactory plugin wiki州：
构建服务器集成 - 在您的服务器中运行Gradle构建时 持续集成构建服务器，建议使用其中之一 Jenkins，TeamCity或Bamboo的Artifactory插件进行配置 通过构建信息捕获解析并发布到Artifactory， 通过您的构建服务器UI。
所以，有些问题可以促进对话：
我真的希望听到这些工具的现有用户以及可能导致他们采用上述方法之一的陷阱/要求（或者甚至是我尚未考虑过的更好的方法）。
答案 0 :(得分：2)
使用工件逻辑混乱构建脚本是否有意义？添加开发人员不部署可能会有所帮助。目前，我只看到从Jenkins任务上传的构建工件。
我会说这是要走的路。您的构建服务器是单一的事实，只应部署构建服务器中构建的工件。
如果CI服务器关闭，是否将所有这些构建逻辑留在任务配置中会使我们面临问题？
那个很简单 - 在CI服务器关闭时不应该部署。在本地计算机上构建可能会产生错误的工件，不应该部署它们。
通过CI接口完成工件更改的版本控制怎么样？
不确定我理解你的问题。
我见过简单的Bamboo配置，通过CI服务器UI指定构建工件，而不是pom。这只是一个糟糕的构建实践吗？
这种配置忽略了Maven的部署能力，我不确定我能找到一个好的方案来证明它的合理性。我唯一能想到的是延迟部署，但Artifactory插件可以解决这个问题。
是否存在杀手工具集成功能，将其中一种方法与另一种方法分开？
现在我们得到了本质:)
那么，定义在构建脚本中部署的内容（在Gradle的情况下）的优势使您可以灵活地微调部署的每个方面（考虑在某些情况下可能要添加的动态属性） 。另一个非常重要的优点是您的构建是源代码，这意味着它在您的版本控制中是可版本化的。
在构建服务器配置中定义部署详细信息的优点是构建服务器是部署应该发生的唯一位置。因此，如果您的构建脚本中没有部署详细信息，那么您肯定知道它不会单独部署。
那么，你如何将两者结合起来以获得两个世界的优势呢？
使用Artifactory插件DSL在Gradle脚本中编写部署逻辑。提供属性的用户名和密码等详细信息，仅存在于构建服务器上。
构建信息对象有用吗？
非常有用。 buildInfo中的信息是在构建过程中收集的，而buidInfo是唯一存在的地方。拥有此信息是您将来能够重现此版本的唯一选择。
仅在Jenkins Artifactory插件中提供，而不是Gradle Artifactory插件吗？