1

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

  1. 使用Jenkins Artifactory 插件在 Jenkins 中指定特定任务的工件设置。
  2. 使用Gradle Artifactory 插件在 Gradle 构建脚本中指定工件设置。
  3. 使用标准Gradle“maven”插件在 Gradle 构建脚本中指定通用 maven repo 设置。

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

为了让我更加困惑，Gradle Artifactory 插件 wiki指出：

构建服务器集成 - 在持续集成构建服务器中运行 Gradle 构建时，建议使用适用于 Jenkins、TeamCity 或 Bamboo 的 Artifactory 插件之一通过构建服务器 UI 配置分辨率并通过构建信息捕获发布到 Artifactory。

因此，一些问题可以让对话继续进行：

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

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

4

1 回答 1

2

用工件逻辑混淆构建脚本是否有意义？添加开发人员不部署可能会有所帮助。目前，我只看到从 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 构建服务器）。

于 2013-07-03T08:45:52.683 回答