跳到主要内容

企业最佳实践

前面 16 篇讲"能做什么"，本篇讲"团队怎么长期用好 Jenkins"。技术选型之外，CI/CD 的真正成败在于规范、可维护性和协作边界。

本篇目标：能把 Jenkins 实践沉淀为团队规范，理解 Pipeline as Code 和 GitOps 的分工，搭建可持续演进的 CI/CD 体系。

1. Pipeline as Code 落地​

1.1 铁律：流水线在 Git 里，不在 UI 里​

✅ 正确：Jenkinsfile 存放在业务代码仓库根目录
❌ 错误：在 Jenkins Web UI 手工编辑 Pipeline

原因：
- 流水线与代码同版本，可回溯、可评审
- 分支/环境自然对应
- 新团队接手能看懂

多分支流水线（第 7 篇）+ 共享库（第 8 篇）是落地的组合拳。

1.2 仓库与目录规范​

业务仓库/
├── Jenkinsfile                 # 顶层流水线入口（尽量精简）
├── deploy/                     # 部署清单
│   ├── helm/
│   └── overlays/
│       ├── dev/
│       ├── staging/
│       └── prod/
└── .gitlab-ci.yml 或等价       # 如果同时用平台内置 CI

1.3 模板化接入​

新项目接入 Jenkins 的步骤：
1. 复制团队统一的 Jenkinsfile 模板
2. 修改业务参数（模块、镜像名、环境清单）
3. 在共享库中注册镜像仓库、通知渠道等平台配置
4. MR 评审通过后合并

模板化让"接入新项目"从几小时降到十几分钟，同时保证所有项目流水线风格一致。

2. 组织与协作规范​

2.1 谁管什么​

角色负责权限
平台/DevOps 团队Jenkins 实例、共享库、Agent、凭证、安全基线Admin、共享库写权限
应用团队业务仓库 Jenkinsfile、部署参数自己 Folder 下 Job 的 Build/Configure
开发触发构建、查看结果Job/Read + Build
值班处理构建失败和平台告警相关 Job + 通知群

2.2 变更流程​

  • 共享库、Agent 模板、平台配置改动走 MR + 评审；
  • 先在一批测试仓库灰度（@Library('...@main')），验证后再发布版本；
  • 所有生产 Job 从 Git 管理，禁止 UI 直接改。

3. CI/CD 流水线规范​

3.1 一条规范的流水线​

1. 检出代码（checkout scm）
2. 编译构建（build）
3. 单元测试（test，可并行）
4. 代码质量（sonar / lint）
5. 集成测试（可选，环境独立）
6. 打包镜像（build & push）
7. 部署 dev
8. 部署 staging（门禁）
9. 人工确认 → 部署 prod
10. 全链路验证（健康检查、冒烟）
11. 通知 + 归档

3.2 规范要点​

维度规范
镜像tag 可追溯（SHA + 语义 tag），不可变
环境dev → staging → prod 逐级，不跳过门禁
回滚部署即记录回滚路径，失败自动/快速回滚
参数环境、版本走 parameters，不写死
清理构建后 cleanWs，产物归档/上传
通知失败必通知，成功可静默（changed）

4. 与 GitOps 的分工​

现代生产环境 Jenkins 不应该是唯一部署通道。推荐分层：

Jenkins 职责：构建、测试、产出可部署产物（镜像）
     ↓ 产物就绪后更新 Git 中的镜像 tag
Argo CD 职责：检测 Git 变更，把产物同步到集群
     ↓
Kubernetes：运行、调度、自愈
// Jenkins 只更新 Git 声明，不直连集群
stage('更新 Git 镜像 tag') {
    steps {
        sh '''
            sed -i "s#tag: .*#tag: v${BUILD_NUMBER}#" config/overlays/prod/image.yaml
            git add config/overlays/prod/image.yaml
            git commit -m "release: backend v${BUILD_NUMBER}"
            git push
        '''
    }
}
决策推荐
能走 GitOps 的部署尽量走 GitOps，Jenkins 不直连生产集群
无法 GitOps 的紧急变更用 Jenkins 部署 Job，但要留痕、评审
数据库迁移独立于应用部署，有独立迁移/回滚方案
分清"构建流水线"和"部署流水线"

构建流水线（Build Pipeline）在 Jenkins，部署状态（谁在哪个环境跑哪个版本）以 Git 和集群为事实源。职责不清时，"部署后线上版本漂移、谁改的都说不清"是最常见问题。

5. 持续演进与度量​

5.1 该度量什么​

指标反映
构建成功率CI 健康度
平均构建时长 / 排队时长流水线效率
从提交到上线的时长（Lead Time）交付效率
失败恢复时长（MTTR）排障能力
变更失败率发布质量

5.2 定期复盘​

  • 每周看构建失败 Top 原因，修复重复失败；
  • 每月评审共享库、模板、镜像版本是否过时；
  • 每次故障后更新排障手册（第 16 篇）。

6. 落地检查清单​

  • 所有业务流水线在 Git 仓库（Pipeline as Code）
  • 有团队统一的 Jenkinsfile 模板和共享库
  • 平台/应用/开发的权限边界清晰
  • 流水线规范：门禁、回滚、通知、清理
  • 部署尽量走 GitOps，Jenkins 不直连生产
  • 有构建成功率、时长、Lead Time 等度量
  • 定期复盘和更新排障手册

7. 练习与验收​

练习 A

  1. 把团队某个业务仓库的 Jenkinsfile 从 UI 迁移到仓库根目录
  2. 用共享库统一它的构建和通知逻辑
  3. 为它加上"部署到生产前人工确认"的门禁

练习 B

  1. 制定一份团队的 CI/CD 规范（模板、门禁、回滚、通知）
  2. 评估当前 Jenkins 是否能"尽量走 GitOps"部署，列出改造点
  3. 建立构建成功率 / 时长 / Lead Time 的监控看板

验收清单

  • 理解 Pipeline as Code 的必要性，业务流水线在 Git
  • 能设计团队模板 + 共享库的复用模式
  • 有清晰的角色与权限边界
  • 理解 Jenkins 与 Argo CD 的分工，部署尽量走 GitOps
  • 有 CI/CD 效率度量与定期复盘机制

这是本手册的最后一篇。恭喜完成 Jenkins 运维实战手册的学习。