模块化运维部署的核心是通过Groovy函数封装、Shared Library抽离和声明式编排，将重复逻辑拆解为可复用、可组合、可独立验证的单元；如在vars中定义deployToK8s()、src中编写ConfigValidator，Jenkinsfile仅按环境参数调用，实现一处修改全局生效。
模块化运维部署的核心，是把重复、分散、耦合的部署逻辑拆解成可复用、可组合、可独立验证的单元。Jenkins Pipeline 本身不提供原生“模块”语法，但通过 Groovy 的函数封装、共享库（Shared Libraries）和声明式结构设计，完全可以实现真正意义上的模块化。
用自定义函数封装通用操作
将构建、镜像推送、K8s 部署等高频动作抽象为带参数的函数，避免在每个 stage 里重复写 shell 命令或 withCredentials 块。
- 在 Jenkinsfile 顶部或 vars 目录下定义 buildAndPushDockerImage(imageName, tag, contextPath)，内部统一处理登录、构建、推送逻辑
- 封装 waitForK8sResourceReady(kind, name, namespace, timeout = 300)，用于轮询 Deployment/StatefulSet 的 ReadyReplicas 或 Pod 状态
- 所有函数统一处理错误重试、日志标记和失败中断，比如用
sh "set -e; kubectl rollout status ..."+timeout步骤包裹
引入 Shared Library 统一管理模块
把跨项目的通用能力（如 Helm 渲染、配置注入、灰度校验）抽离到 Git 仓库，通过 Jenkins 全局配置加载。这样修改一次，所有 Pipeline 自动生效。
- 在
vars/deploy.groovy中提供deployToK8s(config)方法，接收 YAML 路径、命名空间、标签等参数 - 在
src/org/example/validator.groovy中编写ConfigValidator.checkYamlSyntax()，供多个项目调用 - Jenkinsfile 中只需写
deploy.deployToK8s([yaml: 'k8s/deployment.yaml', ns: 'prod'])，语义清晰且无重复代码
按环境与角色分层组织 Pipeline 结构
避免一个 pipeline 涵盖 dev/test/prod 全流程。用 when 条件和参数驱动不同分支走不同模块组合，让每个环境有自己的“部署契约”。
- 开发环境：只运行
buildAndPushDockerImage+deployToK8s(devConfig)，跳过安全扫描和审批 - 生产环境：增加
runSecurityScan()、requireManualApproval('prod')、deployWithCanary(...)模块 - 所有环境共用同一套函数和库，差异仅体现在参数和 stage 编排顺序上
用 parallel + stage 天然支持模块并行与隔离
模块不是越细越好，关键要符合职责单一和故障域隔离原则。把无依赖的服务构建、测试、部署拆成并行 stage，本身就是模块化落地。
- 例如 datawriter、game-ucenter、dataloader 三个服务，各自有独立的
Build和Deploystage，失败互不影响 - 每个 stage 内部调用封装好的函数，不暴露底层命令细节
- Blue Ocean 界面能直观看到哪些模块成功/失败，定位问题快于翻日志
