在我目前工作的一家公司里，我们的大多数Jenkins作业都是脚本化的，它们所做的就是用python或bash调用外部脚本，这些脚本实际上完成了繁重的工作。
timestamps { stage('deploy-site') { sh('python deploy-script.py') } }
我想知道这实际上是否是一个好的实践，以及使用Groovy和Jenkins API编写作业步骤是否会更好。有什么想法吗？每种方法的优缺点是什么？
92dk7w1h1#
我认为这在很大程度上取决于您使用Jenkins的目的。Jenkins可以用于自动化所有类型的事情，而不仅仅是持续集成。我使用它来修补服务器、应用程序和数据库，自动化灾难恢复步骤，完全替代公司范围内的Cron，等等。因此，在我的情况下，Groovy中没有太多的API来处理这些事情。因此，我的方法与您的方法非常相似。但是，我确实围绕这些过程构建了许多用Groovy编写的逻辑，例如知道在哪里运行东西、哪个服务器当前是生产服务器、哪个是灾难恢复。我使用Groovy功能来设置参数、发送电子邮件移动文件等。最好的事情之一是日志记录。我所有的脚本都转到STDOUT，这样Jenkins就可以捕获它，并可以使用它的日志解析功能来解析错误。所以即使在用shell脚本做繁重的工作时，Jenkins也带来了很多增强功能。
c9qzyr3d2#
问题是，团队中是否真的有人必须手动运行python deploy-script.py？如果是，那么维护deploy-script.py是一条可行的路，因为您无法轻松地在Jenkins之外手动运行Jenkins代码。
python deploy-script.py
deploy-script.py
ebdffaop3#
希望那些被调用的脚本处于某种版本控制之下。否则，如果它们在不同的构建节点上运行，则必须维护这些脚本的更新可能会有问题。如果是后者，我会把它们放在一个git repo中，并在必要时为每次构建克隆它们。
tmb3ates4#
如果团队中的每个人都是PythonMaven，那么为什么不这样做呢？我认为在jenkins声明性管道中加入更多的逻辑可以帮助统一多个工件/团队的构建过程，因为它有一个特定的结构，而且它可能有助于在生产代码和构建代码之间进行分离。
rfbsl7qr5#
这绝对是一个很好的实践，尤其是在脚本逻辑很复杂的情况下，因为它允许您以手动和自动方式隔离地测试脚本。除了不必用Groovy编写复杂的逻辑，在我看来这并不是那么灵活。话虽如此，我同意这也归结为你的团队在特定语言方面的经验有多丰富。
5条答案
按热度按时间92dk7w1h1#
我认为这在很大程度上取决于您使用Jenkins的目的。Jenkins可以用于自动化所有类型的事情，而不仅仅是持续集成。我使用它来修补服务器、应用程序和数据库，自动化灾难恢复步骤，完全替代公司范围内的Cron，等等。因此，在我的情况下，Groovy中没有太多的API来处理这些事情。因此，我的方法与您的方法非常相似。但是，我确实围绕这些过程构建了许多用Groovy编写的逻辑，例如知道在哪里运行东西、哪个服务器当前是生产服务器、哪个是灾难恢复。我使用Groovy功能来设置参数、发送电子邮件移动文件等。最好的事情之一是日志记录。我所有的脚本都转到STDOUT，这样Jenkins就可以捕获它，并可以使用它的日志解析功能来解析错误。所以即使在用shell脚本做繁重的工作时，Jenkins也带来了很多增强功能。
c9qzyr3d2#
问题是，团队中是否真的有人必须手动运行
python deploy-script.py？如果是，那么维护deploy-script.py是一条可行的路，因为您无法轻松地在Jenkins之外手动运行Jenkins代码。ebdffaop3#
希望那些被调用的脚本处于某种版本控制之下。否则，如果它们在不同的构建节点上运行，则必须维护这些脚本的更新可能会有问题。
如果是后者，我会把它们放在一个git repo中，并在必要时为每次构建克隆它们。
tmb3ates4#
如果团队中的每个人都是PythonMaven，那么为什么不这样做呢？
我认为在jenkins声明性管道中加入更多的逻辑可以帮助统一多个工件/团队的构建过程，因为它有一个特定的结构，而且它可能有助于在生产代码和构建代码之间进行分离。
rfbsl7qr5#
这绝对是一个很好的实践，尤其是在脚本逻辑很复杂的情况下，因为它允许您以手动和自动方式隔离地测试脚本。
除了不必用Groovy编写复杂的逻辑，在我看来这并不是那么灵活。
话虽如此，我同意这也归结为你的团队在特定语言方面的经验有多丰富。