第 8 章 · 02 Jenkins与流水线实践

第 8 章 · 02 Jenkins与流水线实践

Jenkins 是 CI/CD 界服役最久的工具，其概念体系（Job/Build/Node/Executor）是理解一切流水线系统的通用语言。本节先建立这套概念，再对比声明式与脚本式两类 Pipeline，接着覆盖多节点并行、失败通知、从指定阶段启动等实战技巧，最后给出可落地的 CI/CD 最佳实践清单。

学习目标

• 说清 Job/Build/Node/Executor 四个概念及其关系
• 对比声明式与脚本式 Pipeline 的取舍
• 会用 parallel 块实现多节点并行构建
• 掌握失败通知与从指定阶段启动的方法
• 熟记 CI/CD 最佳实践清单

一、核心概念：Job、Build、Node、Executor

最常见的混淆点：Executor 是"并发槽位"不是独立节点——一个 Worker 配 3 个 Executor，表示该机器可同时跑 3 个 Build（不一定是同一 Job）。Jenkins 的价值定位：开源、插件生态庞大（Artifactory、Git、Editable Email Notification、Cobertura、JUnit 等）、与几乎一切工具集成；局限则是插件质量参差、配置漂移、大规模管理成本高。

二、声明式 vs 脚本式 Pipeline

两种语法风格：

脚本式（Scripted）：Groovy 语言，灵活、控制力强，可写自定义代码处理复杂场景——但复杂难维护。

声明式（Declarative）：结构化、固定阶段定义，内置条件与错误处理——易上手、易维护、出错风险低。多数场景倾向声明式。

pipeline {
    agent any
    stages {
        stage('Build') {
            steps { /* 构建命令 */ }
        }
        stage('Test') {
            steps { /* 测试命令 */ }
        }
        stage('Deploy') {
            steps { /* 部署构建产物 */ }
        }
    }
}
​

三、多节点并行与失败通知

一个 Build 同时使用多个节点，用 parallel 块 + 每 stage 指定 agent label：

pipeline {
    agent any
    stages {
        stage('Build') {
            parallel {
                stage('Node 1') { agent { label 'node1' } steps { /* 构建 */ } }
                stage('Node 2') { agent { label 'node2' } steps { /* 构建 */ } }
                stage('Node 3') { agent { label 'node3' } steps { /* 构建 */ } }
            }
        }
        stage('Deploy') {
            agent any
            steps { /* 部署构建产物 */ }
        }
    }
}
​

失败通知：Editable Email Notification 插件，模板中用 {BUILD_URL}、{BUILD_LOG}，触发条件选 "Only on failure"——只在失败时发邮件，避免"告警疲劳"。通知渠道（邮件/消息应用/看板）各有优劣，邮件过频会被忽视。

从指定阶段启动：生产事故后想跳过已验证的阶段，用参数 + when 指令：

parameters {
    string(name: 'START_STAGE', defaultValue: '', description: '要开始执行的阶段名')
}
stage('Build') {
    when { expression { params.START_STAGE == '' || currentStage.name == params.START_STAGE } }
}
​

触发时传参 pipeline?START_STAGE=Test，即可跳过 Build 直接从 Test 开始。

四、构建产物管理

• 用 Artifactory 类插件发布/获取二进制与依赖；
• 归档相关日志与文件（Archive the relevant logs/files）；
• 覆盖率报告（Cobertura）、测试报告（JUnit）作为构建产物——测试结果要有地方看，否则等于没测。

大规模管理（数百个 Job）：Job 模板、Job DSL、Jenkins REST API、配置管理工具、专门的 Job 管理工具。构建优先级：多团队共享 Jenkins 时，用优先级插件按团队/任务类型排队，避免低价值构建堵死高价值构建。

五、CI/CD 最佳实践清单

1. 频繁提交 + 频繁测试——反馈回路越短，问题越早暴露；
2. 测试/暂存环境是生产环境的克隆——环境不一致，测试结果没有意义；
3. 流水线创建的资源要自己清理——不清理会累积浪费；
4. 本地执行与远程执行结果一致——不一致会让 CI 失去意义；
5. 把 CI/CD 当作组织内的一等应用，而非"胶水代码"——它值得正式维护；
6. 按需环境，而非为 CI/CD 预分配资源——弹性使用，不为闲置付费；
7. 流水线的 Stage/Step/Task 在应用/微服务间共享——不要每个项目重复造轮子。

补充两条设计原则：依赖多个应用的 CD 要定义部署顺序、版本控制与依赖管理、滚动部署、依赖监控与回滚策略；执行环境（VM/裸金属/容器）选型依据：流水线需求、资源可用性、扩展性、隔离要求、安全、工作流与成本。

小结

本节把 Jenkins 讲成了"流水线通用语言"：Job/Build/Node/Executor 概念可迁移到任何 CI 系统；声明式 Pipeline 是默认选择；parallel 多节点、失败通知、从指定阶段启动构成实战三板斧；最佳实践清单是团队落地 CI/CD 的检查表。推送式流水线把代码变成镜像与清单——但"清单怎么变成集群现实"这件事，推送式工具做得并不优雅，GitOps 给出了更好的答案。

下一节预告

第 8 章第 3 节《GitOps与ArgoCD》将讲解 Git 仓库作为唯一事实来源的拉取式部署模型，以及 Application、同步策略、自愈与 Argo Rollouts 的自动回滚。