Jenkins Pipeline 脚本踩坑记：我是如何被两种语法折磨并最终选择的

最近在折腾公司的 CI/CD 流水线想把原来那套老掉牙的构建脚本升级一下。本以为 Jenkins Pipeline 挺简单的结果一上手就懵了——竟然有两种写法这不是逼死选择困难症吗我当时的内心OS这玩意儿就像去饭店点菜服务员问你要清汤还是麻辣的你以为选完就完事了结果又问你要不要加香菜、要不要加醋… 选择太多反而不知道怎么选了。Pipeline 的两种口味Jenkins Pipeline 主要有两种写法Declarative Pipeline声明式流水线和 Scripted Pipeline脚本式流水线。Declarative Pipeline 就像是傻瓜相机你只需要按快门就行其他的都帮你调好了。它用的是一种 DSLDomain Specific Language说白了就是专门为 Pipeline 设计的语言。整个 Pipeline 必须包在pipeline块里面然后用stages和steps来组织你的构建步骤。而 Scripted Pipeline 呢更像是单反相机功能强大但你得自己调参数。它直接用的是 Groovy 语言灵活性爆表但也意味着你得有点 Groovy 基础。整个脚本是在node块里执行的[4]。我的踩坑之旅第一坑语法差异刚开始我用的是 Declarative Pipeline写起来确实简单pipeline{agent any stages{stage(Build){steps{echoBuilding...}}}}看着挺清爽的对吧结构一目了然。后来有个需求需要在构建过程中动态判断一些条件我就想着用 if-else。结果发现 Declarative Pipeline 里不能直接写 if 语句你得用when指令stage(Deploy){when{branchmaster}steps{echoDeploying to production...}}这时候我就想要不试试 Scripted Pipeline切换过去一看node{stage(Build){echoBuilding...if(env.BRANCH_NAMEmaster){echoThis is master branch}}}嘿这下自由了想怎么写就怎么写。但问题又来了…第二坑错误处理Declarative Pipeline 的错误处理特别规范有专门的post块pipeline{agent any stages{stage(Test){steps{shmake test}}}post{always{echoThis will always run}success{echoOnly on success}failure{echoOnly on failuremail to:teamexample.com,subject:Build Failed}}}但在 Scripted Pipeline 里你得自己写 try-catchnode{try{stage(Test){shmake test}echoSuccess!}catch(e){echoFailed!throwe}finally{echoCleanup}}说实话写多了 try-catch 真的很烦。有一次我忘了写 finally 块结果构建失败后一些临时文件没清理磁盘差点爆了。第三坑并行执行这个是我觉得两种 Pipeline 差异最大的地方。Declarative Pipeline 的并行执行写法很直观pipeline{agent any stages{stage(Parallel Stage){parallel{stage(Unit Tests){steps{echoRunning unit tests...}}stage(Integration Tests){steps{echoRunning integration tests...}}}}}}而 Scripted Pipeline 的写法… 说实话第一次看到我是懵的node{stage(Parallel Stage){parallel(Unit Tests:{echoRunning unit tests...},Integration Tests:{echoRunning integration tests...})}}这种 Map 的写法不知道为啥总让我想起 JavaScript 的对象字面量。实战经验分享经过这么多坑我总结了一些实战经验。如果你的项目比较简单构建流程相对固定强烈建议用 Declarative Pipeline。为啥因为它语法检查更严格写错了立马报错结构清晰新人上手快自带很多实用功能比如options、parameters、triggers等[3]我们有个前端项目就是用的 Declarativepipeline{agent{docker{imagenode:14-alpine}}options{timeout(time:30,unit:MINUTES)buildDiscarder(logRotator(numToKeepStr:10))}parameters{choice(name:ENVIRONMENT,choices:[dev,test,prod],description:Deploy environment)}stages{stage(Install){steps{shnpm ci}}stage(Build){steps{shnpm run build:${params.ENVIRONMENT}}}stage(Deploy){when{expression{params.ENVIRONMENTprod}}steps{input message:Deploy to production?sh./deploy.sh}}}}但如果你的构建逻辑很复杂需要大量的条件判断、循环处理或者要调用很多 Groovy 的高级特性那 Scripted Pipeline 可能更合适。我们有个数据处理的项目需要根据不同的数据源动态生成构建步骤node{defdataSources[mysql,postgres,mongodb]defstages[:]dataSources.each{source-stages[Process${source}]{stage(Process${source}){echoProcessing${source}data...defconfigreadJSON file:${source}.jsonconfig.tables.each{table-shpython process.py --source${source}--table${table}}}}}parallel stages}这种动态生成 stage 的需求用 Declarative 就很难实现了。性能和维护性对比从性能角度看两者其实差不多。Jenkins 最终都会把它们转换成同样的执行逻辑。但从维护性来说Declarative Pipeline 胜出太多了。我们团队之前有个项目用的 Scripted Pipeline写得那叫一个自由奔放。后来换了个人维护看着那些嵌套的闭包和各种 Groovy 黑魔法直接崩溃了。最后花了一周时间重写成 Declarative 的。我的最终选择折腾了这么久我的选择是能用 Declarative 就用 Declarative实在不行再用 Scripted。为啥因为大部分场景下Declarative Pipeline 真的够用了。而且 Jenkins 官方也推荐优先使用 Declarative。它的限制反而是优点能让团队的 Pipeline 风格保持一致。当然如果你遇到这些情况可能真的需要 Scripted Pipeline需要复杂的流程控制逻辑要动态生成大量的 stages需要使用 Groovy 的高级特性要集成一些特殊的 Jenkins 插件一些实用技巧不管用哪种 Pipeline这些技巧都很有用使用共享库把通用的逻辑抽取到共享库里避免重复代码参数化构建灵活使用 parameters让 Pipeline 更通用合理使用 agent不同的 stage 可以用不同的 agent提高资源利用率做好错误处理该 catch 的要 catch该重试的要重试日志要清晰多用 echo 输出关键信息方便排查问题总结Jenkins Pipeline 的两种写法各有千秋。Declarative Pipeline 像是给你画好了框你只需要往里面填东西Scripted Pipeline 则是给你一张白纸你想怎么画就怎么画。我的建议是如果你刚接触 Jenkins Pipeline从 Declarative 开始。等你熟悉了再根据实际需求决定是否需要 Scripted 的灵活性。记住工具是为了解决问题的不要为了炫技而选择复杂的方案。最后不管选择哪种记得多写注释相信我三个月后的你会感谢现在的自己的。如果这篇文章对你有帮助欢迎关注运维躬行录我会持续分享更多运维实战经验。遇到 Pipeline 的坑也欢迎留言交流说不定我也踩过呢公众号运维躬行录个人博客躬行笔记