我是否在构建脚本或 CI 服务器中指定二进制工件设置？

Question

我正在使用Jenkins、Gradle 和Artifactory 对新的构建系统进行原型设计。在指定构建工件及其目的地方面，这些工具中似乎存在冲突或重叠的功能。我看到了三个前进的道路：

1. 使用 Jenkins Artifactory plugin 在 Jenkins 中指定特定任务的工件设置。
2. 使用 Gradle Artifactory plugin 在 Gradle 构建脚本中指定工件设置。
3. 使用标准 Gradle "maven" plugin 在 Gradle 构建脚本中指定通用 maven 存储库设置。

我看到了所有这些方法的优缺点，但据我所知，我们的构建没有缺少关键功能。

为了让我更加困惑，Gradle Artifactory plugin wiki 声明：

构建服务器集成 - 在您的系统中运行 Gradle 构建时 持续集成构建服务器，推荐使用其中之一 用于配置 Jenkins、TeamCity 或 Bamboo 的 Artifactory 插件 通过构建信息捕获解决并发布到 Artifactory， 通过您的构建服务器 UI。

所以，有一些问题可以让对话继续进行：

1. 将构建脚本与工件逻辑混为一谈有意义吗？添加开发人员不部署可能会有所帮助。目前，我只看到从 Jenkins 任务上传的构建工件。
2. 如果 CI 服务器关闭，将所有这些构建逻辑留在任务配置中是否会使我们面临问题？
3. 对于通过 CI 接口完成的工件更改的版本控制如何？
4. 我见过简单的 Bamboo 配置，它们通过 CI 服务器 UI 而不是 pom 指定构建工件。这只是一种糟糕的构建做法吗？
5. 是否有一种杀手级工具集成功能可以将其中一种方法与另一种方法区分开来？
6. 构建信息对象有多大用处？是否仅在 Jenkins Artifactory 插件中可用，而在 Gradle Artifactory 插件中不可用？

我真的很希望听到这些工具的现有用户的意见，以及哪些陷阱/要求可能导致他们采用上述方法之一（或者甚至可能是我尚未考虑过的更好的方法）。

Answer 1

用工件逻辑混淆构建脚本是否有意义？添加开发人员不部署可能会有所帮助。目前，我只看到从 Jenkins 任务上传的构建工件。

我会说这是要走的路。您的构建服务器是唯一的事实，只有构建在构建服务器中的工件应该被部署。

如果 CI 服务器停机，将所有这些构建逻辑留在任务配置中是否会使我们面临问题？

这很简单 - 您不应该在 CI 服务器关闭时进行部署。在本地机器上构建可能会产生错误的工件，不应部署。

对于通过 CI 接口完成的工件更改的版本控制如何？

不确定我是否理解您的问题。

我见过简单的 Bamboo 配置，它们通过 CI 服务器 UI 而不是 pom 指定构建工件。这只是一种糟糕的构建实践吗？

这个配置忽略了 Maven 的部署能力，我不确定我能找到一个好的场景来证明它的合理性。我唯一能想到的就是延迟部署，但 Artifactory 插件可以解决这个问题。

是否有一个杀手级工具集成功能可以将其中一种方法与另一种分开？

现在我们进入了本质:)

好吧，定义在构建脚本中部署的内容（在 Gradle 的情况下）的优势使您可以灵活地微调部署的各个方面（考虑在某些情况下您可能想要添加的动态属性） .另一个非常重要的优势是您的构建是源代码，这意味着它可以在您的版本控制中进行版本控制。

在构建服务器配置中定义部署细节的好处是构建服务器是唯一应该进行部署的地方。因此，如果您的构建脚本中没有部署详细信息，您肯定知道它不会独立部署。

那么，如何将两者结合起来，获得两全其美的优势呢？

使用 Artifactory 插件 DSL 在 Gradle 脚本中编写部署逻辑。提供来自属性的用户名和密码等详细信息，这些信息仅存在于构建服务器上。

构建信息对象有多大用处？

非常有用。 buildInfo 中的信息是在构建过程中收集的，而 buidInfo 是它存在的唯一位置。拥有此信息是您将来能够重现此构建的唯一选择。

这仅在 Jenkins Artifactory 插件中可用，而不在 Gradle Artifactory 插件中可用？

'artifactory' 和 'artifactory-publish' Gradle 插件都会生成 buildInfo 对象，无论它们在哪里运行（无论是您的本地机器还是 Jenkins 构建服务器）。