Jenkins：使用外部脚本与在 Groovy 中编码工作

Question

在我目前工作的一家公司中，我们的大部分 Jenkins 工作都是脚本化的，他们所做的只是在 python 或 bash 中调用外部脚本，这实际上完成了繁重的工作。 像这样的东西：

timestamps {
  stage('deploy-site') {
    sh('python deploy-script.py')
  }
}

我想知道这是否真的是一个好习惯，以及使用 Groovy 和 Jenkins API 对作业步骤进行编码是否会更好。

有什么想法吗？ 每种方法的优缺点是什么？

Answer 1

问题是，团队中是否有人真的必须手动运行python deploy-script.py ？ 如果是，那么维护deploy-script.py是可行的方法，因为您不能轻松地在 Jenkins 之外手动运行 Jenkins 代码。

Answer 2

我认为这在很大程度上取决于您使用 Jenkins 的目的。 Jenkins 可用于自动化各种事情，而不仅仅是持续集成。 我用它来修补服务器、应用程序和数据库，自动化灾难恢复步骤，完全替代整个公司的 Cron 等等。 所以在我的例子中，Groovy 中没有很多 API 可以处理这些事情，所以我的方法与你那里的方法非常相似。 但是，我确实有很多围绕这些用 Groovy 编写的流程构建的逻辑，比如知道在哪里运行东西，哪个服务器当前正在生产，哪个是 DR。 我将 Groovy 功能​​用于参数、电子邮件、移动文件等。最好的事情之一就是日志记录。 我的所有脚本都转到 STDOUT，以便 Jenkins 捕获并使用其日志解析功能解析错误。 因此，即使在使用 shell 脚本进行繁重的工作时，Jenkins 也带来了很多东西来增强它。

Answer 3

希望那些被调用的脚本处于某种版本控制之下。 如果没有，如果这些脚本在不同的构建节点上运行，则必须维护对这些脚本的更新可能会出现问题。

如果是后者，我会将它们放在 git repo 中，并在必要时为每个构建克隆它们。

Answer 4

如果团队中的每个人都是 python 专家，那为什么不这样做呢。

我认为在 jenkins 声明式管道中添加更多逻辑可以帮助统一跨多个工件/团队的构建过程，因为它具有一定的结构。 此外，它可能有助于在生产代码和构建代码之间进行拆分。

Answer 5

这绝对是一种很好的做法，尤其是在脚本逻辑复杂的情况下，因为它允许您以手动和自动方式单独测试脚本。

除了不必在 Groovy 中编写复杂的逻辑之外，在我看来这不是那么灵活。

话虽如此，我同意这也归结为您的团队在给定语言方面的经验。