3. 流水线阶段划分：代码提交、镜像构建、单元测试、安全扫描、部署审批、生产发布
在K8s平台发布流水线中，阶段划分直接决定了交付效率与安全质量。一个标准的生产级流水线应包含以下六个核心阶段，每个阶段都承载特定的质量门禁与运维职责。
3.1 流水线阶段总览
下表列出了各阶段的触发条件、核心产出物及关键质量门禁，是运维清单设计的基线参考。
| 阶段 | 触发条件 | 核心产出物 | 质量门禁 |
|---|---|---|---|
| 代码提交 | 开发者推送代码至特性分支或PR | Git Commit / PR元数据 | 提交信息规范校验、分支命名规则 |
| 镜像构建 | 代码合并至主干或Tag触发 | 容器镜像 + 镜像摘要 | Dockerfile Lint、基础镜像版本锁定 |
| 单元测试 | 镜像构建成功后自动触发 | 测试报告 + 覆盖率报告 | 覆盖率阈值（≥80%）、零失败用例 |
| 安全扫描 | 单元测试通过后自动触发 | 漏洞清单 + SBOM | 无Critical/High漏洞、许可证合规 |
| 部署审批 | 安全扫描通过后人工/自动触发 | 审批记录 + 变更工单 | 双人审批、变更窗口匹配 |
| 生产发布 | 审批通过后自动执行 | 发布记录 + 回滚脚本 | 灰度比例、健康检查、自动回滚 |
运维清单设计要点：每个阶段的门禁失败后，流水线应自动阻断并通知对应负责人，避免有缺陷的制品流入下游阶段。
3.2 阶段流程关系图
下图展示了六个阶段之间的串行依赖关系与关键决策点，其中“安全扫描”与“部署审批”之间设有强制阻断门禁。
3.3 各阶段运维清单详解
3.3.1 代码提交阶段
- 提交信息规范：必须遵循 Conventional Commits 格式（
feat/fix/chore/docs），便于自动生成 Changelog。 - 分支策略：推荐 Trunk-Based 或 GitFlow，特性分支必须基于最新主干创建。
- 预提交检查：在客户端或CI中运行
git-hooks，校验代码风格、敏感信息泄露（如密钥硬编码）。
运维清单项示例：
# .gitlab-ci.yml 代码提交阶段
commit-check:
stage: commit
script:
- commitlint --from HEAD~1
- detect-secrets scan .3.3.2 镜像构建阶段
- 基础镜像锁定：使用固定SHA256摘要而非标签，避免基础镜像漂移。
- 多阶段构建：分离构建环境与运行环境，减小镜像体积。
- 镜像标签策略：使用
Git Commit SHA作为唯一标识，同时打上latest和v版本号标签。
3.3.3 单元测试阶段
- 覆盖率阈值：行覆盖率 ≥ 80%，分支覆盖率 ≥ 70%，低于阈值则流水线失败。
- 测试隔离：使用
testcontainers或kind启动临时K8s环境，避免依赖共享集群。 - 并行执行：按模块拆分测试套件，利用CI并行能力缩短执行时间。
3.3.4 安全扫描阶段
- 镜像漏洞扫描：集成 Trivy / Grype，扫描操作系统级与语言级依赖。
- SBOM生成：使用 Syft 生成 CycloneDX 格式的软件物料清单，归档至制品库。
- 许可证合规：检查依赖许可证类型，禁止 GPL/AGPL 等传染性许可证进入生产环境。
安全红线：安全扫描阶段发现的 Critical 漏洞必须立即阻断流水线，并通知安全团队。不允许跳过或忽略高危漏洞进入审批阶段。
3.3.5 部署审批阶段
- 审批人策略：至少需要两名审批人，其中一名必须是该服务的技术负责人。
- 变更窗口：生产发布仅允许在定义的变更窗口内执行（如周二/周四 10:00-16:00）。
- 审批工单：自动生成变更工单，包含变更内容、影响范围、回滚方案。
3.3.6 生产发布阶段
- 灰度发布：采用金丝雀发布策略，初始流量比例 5%，逐步提升至 100%。
- 健康检查：发布过程中持续监控 Pod 状态、应用指标（P99延迟、错误率）。
- 自动回滚：若健康检查失败或错误率上升超过 5%，自动触发回滚至上一版本。
3.4 阶段间数据传递与制品管理
流水线各阶段之间需要传递关键元数据，确保下游阶段能够准确引用上游产出物。下表列出了核心传递参数：
| 传递方向 | 传递参数 | 示例值 |
|---|---|---|
| 代码提交 → 镜像构建 | Git Commit SHA | a1b2c3d4e5f6... |
| 镜像构建 → 单元测试 | 镜像完整名称 + 摘要 | registry.example.com/app:sha256:... |
| 单元测试 → 安全扫描 | 测试报告路径 + 覆盖率数据 | reports/coverage.xml |
| 安全扫描 → 部署审批 | 漏洞清单 + SBOM 文件 | reports/vulnerabilities.json |
| 部署审批 → 生产发布 | 审批记录 + 变更工单ID | CHG-20250301-001 |
最佳实践：使用 CI/CD 平台的 artifacts 功能持久化各阶段产出物，并设置合理的保留策略（如安全扫描报告保留90天，镜像保留180天）。
3.5 流水线阶段与Helm准入核验的集成点
在部署审批与生产发布阶段之间，Helm Chart 准入核验是最后一道自动化防线。下图展示了 Helm 核验在流水线中的具体位置：
Helm 准入核验作为部署审批后的自动化检查点，确保所有发布到生产环境的 Chart 包都经过预定义的合规性校验，包括 Chart 版本号规范、values 参数白名单、镜像签名验证等。核验通过后，流水线自动进入生产发布阶段；核验失败则阻断发布并返回审批阶段重新调整。