📚 课程目录第2章 Pipeline构建流程基础

2. Pipeline构建流程基础：阶段划分与关键节点归纳

Pipeline这东西，说白了就是一条自动化生产线。我见过不少团队上来就写Jenkinsfile，结果搞成了一锅粥——构建超时、依赖漏传、产物包名混乱。为什么会这样？因为缺少清晰的阶段划分。

今天我把Pipeline拆成六个标准阶段，每个阶段都有对应的审计控制点。你按照这个框架来设计，基本不会出大问题。

2.1 标准Pipeline的六阶段模型

我个人习惯把Pipeline划分为以下阶段，这也是我在多个大型项目中验证过的结构：

阶段	核心任务	审计关注点	常见问题
代码提交与静态分析	拉取源码、代码风格检查、静态扫描	提交信息规范、扫描报告留存	跳过扫描、报告未归档
构建与产物打包	编译、依赖安装、制品打包	构建环境一致性、依赖锁定	本地编译通过CI失败
单元测试与质量门禁	运行UT、覆盖率检查、质量阈值	测试结果可追溯、门禁规则透明	覆盖率门槛形同虚设
镜像构建与制品推送	Docker镜像构建、推送至制品库	镜像签名、安全扫描、标签策略	latest标签满天飞
部署与验收测试	自动部署至测试环境、冒烟测试	部署日志、回滚能力、验证结果	部署后无人确认
发布审批与灰度放量	人工审批、灰度发布、全量上线	审批记录、灰度比例、回滚预案	审批节点被跳过

这个模型的好处在于——每个阶段的产出物都明确，审计点也清晰。你想想看，如果某个阶段失败了，我们可以立刻定位问题出在哪一环。

2.2 关键节点深度解析

2.2.1 代码检查节点

代码检查点我放在最前面。原因很简单——越早发现问题，修复成本越低。我在项目中遇到过一件事：有个开发同学把数据库密码写死在代码里，静态扫描直接拦截了，才没酿成大祸。

这个节点的审计要点：

必须配置阻断规则（高危漏洞、硬编码密码等）
扫描报告要自动归档到制品库
提交信息必须符合约定格式（如包含JIRA单号）

一个基本的静态扫描配置示例：

sonar-scanner \
  -Dsonar.projectKey=my-app \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://sonar.ops.com \
  -Dsonar.login=${SONAR_TOKEN} \
  -Dsonar.qualitygate.wait=true

注意那个-Dsonar.qualitygate.wait=true参数。如果不加，Pipeline会继续往下走，质量门禁就形同虚设了。

2.2.2 编译打包节点

编译环境的一致性是个大坑。我曾经在处理一个Java项目时，本地JDK版本是11，CI环境是8，结果编译通过但运行报错。为了这个，我花了两天才定位到问题。

所以在这个节点，我强制要求：

使用构建缓存（如Docker层缓存、Maven本地仓库缓存）
依赖文件必须锁定版本（package-lock.json / pom.xml / requirements.txt）
构建产物必须包含版本号+构建时间戳

一个标准的构建脚本片段：

npm ci --only=production
npm run build
tar -czf dist/app-${BUILD_NUMBER}.tar.gz dist/
echo "BUILD_TAG=${BUILD_NUMBER}" > build_metadata.properties
echo "BUILD_TIME=$(date -u '+%Y-%m-%dT%H:%M:%SZ')" >> build_metadata.properties

这里用npm ci而不是npm install，就是为了保证依赖完全锁定。

2.2.3 单元测试与质量门禁节点

单元测试是很多团队的薄弱环节。我记得有个项目，测试覆盖率报告显示90%，但实际业务逻辑完全没有覆盖到。原因是什么？测试用例全是getter/setter的垃圾测试。

质量门禁的审计控制点：

覆盖率阈值（行覆盖≥80%、分支覆盖≥60%）
失败测试用例数必须为0
测试结果XML/Junit格式必须归档

Jenkins Pipeline中集成质量门禁的写法：

stage('Unit Test & Quality Gate') {
    steps {
        sh 'npm test -- --coverage'
        junit 'reports/junit.xml'
        jacoco execPattern: 'build/jacoco.exec'
    }
    post {
        failure {
            error '单元测试或覆盖率未达标，Pipeline终止'
        }
    }
}

这个post failure块就是审计控制点——一旦测试失败或覆盖率不达标，Pipeline直接亮红灯。

2.2.4 镜像构建与推送节点

镜像构建是Docker时代的核心节点。这里最容易出的问题，就是镜像标签混乱。我在一个客户现场看到，所有镜像全是latest标签，根本不知道哪个是生产版本。

我的建议：

镜像标签使用应用名-构建号-提交ID前七位
必须进行镜像安全扫描（Trivy/Clair）
推送前做签名验证（Notation/Cosign）
制品库设置不可变标签（防止覆盖）

一个带审计的镜像构建命令示例：

docker build \
  --build-arg APP_VERSION=${BUILD_NUMBER} \
  -t registry.ops.com/my-app:${BUILD_NUMBER}-${GIT_COMMIT:0:7} \
  .

trivy image --exit-code 1 --severity HIGH,CRITICAL \
  registry.ops.com/my-app:${BUILD_NUMBER}-${GIT_COMMIT:0:7}

docker push registry.ops.com/my-app:${BUILD_NUMBER}-${GIT_COMMIT:0:7}

cosign sign --key cosign.key \
  registry.ops.com/my-app:${BUILD_NUMBER}-${GIT_COMMIT:0:7}

你看，构建、扫描、推送、签名，四步一步都不能少。

    审计关键点： 镜像签名和扫描结果必须作为构建产物的一部分归档，否则后期追溯根本查不到。

2.2.5 部署与验收节点

部署节点我单独提出来说，因为它最容易被审计遗漏。很多团队觉得部署完就OK了，其实不然。

这个节点的审计控制：

部署前必须有回滚脚本且经过验证
部署日志必须实时输出且持久化存储
验收测试必须包含冒烟用例（至少3个核心接口）
失败时自动触发回滚流程

一个带回滚机制的K8s部署示例：

kubectl set image deploy/my-app my-app=registry.ops.com/my-app:${BUILD_NUMBER}
kubectl rollout status deploy/my-app --timeout=300s

if [ $? -ne 0 ]; then
  echo "部署超时，触发回滚"
  kubectl rollout undo deploy/my-app
  exit 1
fi

这里用kubectl rollout status来等待部署完成，超时就回滚。审计日志里必须记录这次回滚操作。

2.2.6 审批与发布节点

到了发布节点，人工审批是最后的防线。我个人习惯把审批分成两档：

测试环境发布：自动审批（质量门禁通过即可）
生产环境发布：必须人工审批+二次确认

审批记录必须包含：审批人、审批时间、审批结论、关联的构建ID。这些信息后期审计都要查。

避坑指南： 我曾经见过一个团队，审批流里有个"跳过审批"的按钮，结果生产发布时所有人都点了它。后来出了故障，审计连责任人是谁都找不到。这个按钮必须去掉。

2.3 Pipeline核心流程的图形化表示

下面的图是我归纳的Pipeline核心流程。每个阶段都标记了对应的审计控制节点，你照着这个结构去设计Pipeline，基本不会漏掉关键点。

提示： 图中的虚线回滚路径是很多团队容易忽略的。记住，部署失败不等于Pipeline结束——必须触发回滚，并且回滚操作本身也要留审计日志。

2.4 关键节点汇总清单

最后，我把所有关键节点整理成一份清单。你设计Pipeline的时候，可以逐条对照检查：

代码检查：是否配置了阻断规则？报告是否归档？
编译打包：依赖是否锁定？环境是否容器化？产物是否带版本号？
单元测试：覆盖率阈值是否生效？失败用例是否阻断Pipeline？
镜像构建：是否做了安全扫描？镜像签名是否完成？标签是否符合规范？
部署验收：是否有回滚脚本？部署日志是否完整？验收测试是否包含冒烟用例？
发布审批：审批人、时间、结论是否记录？是否有跳过审批的旁路？

嗯，这套框架我用了快五年。每次设计新的Pipeline，我都会先画出这个六阶段模型，然后逐一配置审计节点。效果很明显——审计过一次后再也没出过问题。