用 Shared Library 收敛三十条 Jenkins 流水线

三十多个仓库各自一份 Jenkinsfile，复制粘贴的后果是改一次公共逻辑要动三十个仓库。Shared Library 重构后，业务仓库的 Jenkinsfile 平均不到 20 行。

结构上按官方建议分三层：vars 目录放全局可调用的步骤，是业务直接面对的接口；src 放 Groovy 类承载复杂逻辑；resources 放公共脚本模板。

// vars/buildService.groovy
def call(Map cfg) {
  cfg = [skipTest: false, jdk: 21] + cfg
  node (cfg.label ?: 'docker') {
    stageCheckout()
    stageBuild cfg
    if (!cfg.skipTest) {
      stageTest cfg
    }
    stageDocker cfg
    stageDeploy cfg
  }
}

业务侧的 Jenkinsfile 就剩一句话：buildService name: order-svc, replicas: 4。复杂度被推到了库里，而库有版本和评审。

版本治理是重点。库的变更走独立 Git 仓库加 code review，Jenkins 里配置固定版本号而不是 main 分支，防止某次库更新悄悄炸掉全部流水线。灰度做法：新版本先在两个试点仓库用显式版本引用，跑稳一周再全局切默认。

踩过一个大坑：库方法里直接改全局 env 和 currentBuild 有作用域问题，公共步骤尽量传参而不是读写全局状态。另一个是沙箱限制，@NonCPS 注解要用在刀刃上。

收益账很好算：发布模板升级从三十处改动变成一处，新服务接入从半天到十分钟。流水线代码也是代码，值得同等待遇。

顺带一提灰度策略在库层面的实现：通过全局变量控制新旧逻辑开关，试点仓库先走新路径，稳定后一刀切换。库的每次破坏性变更都保留一个兼容版本过渡期，给业务仓库留足迁移时间，这是公共库维护的基本礼貌。

库化之后另一个收益浮现：三十几条流水线的行为终于一致了，之前各仓库自己魔改的部署逻辑产生的环境差异，花了一个季度逐个收编。抽象的代价是库的维护责任变重，我们指定了两名负责人并轮值，避免单点。公共代码库的命运取决于有没有人真心对它负责，没有 owner 的公共库比没有库更危险。