第四章 灰度发布前置条件：代码合并、单元测试、集成测试、安全扫描

适用场景

• 研发团队已完成特性开发，准备将特性分支合并至主干或预发分支进行灰度验证。
• CI/CD 管道已配置但需要明确质量门禁（Quality Gates）的触发条件与通过标准。
• 多团队协作开发，需要统一灰度发布的准入基线，降低集成风险。

前置条件

• 特性分支代码已通过本地开发自测（含新增用例）。
• CI/CD 基础管道（GitLab CI/GitHub Actions/Jenkins）处于健康运行状态。
• 测试环境（集成测试环境、安全扫描环境）已就绪或可通过 IaC 动态创建。
• 安全扫描工具（SonarQube/Snyk/Trivy）与制品库（Harbor/Artifactory）已完成 API 集成。

操作步骤

1. 代码合并与审查：开发者发起 Pull/Merge Request，指定审查者。CI 自动触发静态代码检查与风格校验。分支策略推荐使用 Squash Merge 保持主干历史线性。
2. 单元测试阶段：触发自动化单元测试套件执行。收集覆盖率报告与测试结果。覆盖率阈值（≥80%）与失败用例数（0失败）作为硬性门禁。
3. 集成测试阶段：部署集成环境，运行契约测试（PACT）、API 自动化测试与数据迁移测试。确保新老模块间接口兼容性。
4. 安全扫描阶段：并行执行 SAST（静态应用安全测试）、SCA（软件组成分析）与容器镜像漏洞扫描。结果汇总至安全仪表板。
5. 产物发布就绪：上述阶段全部通过后，自动将构建产物（Docker 镜像/程序包）推送至制品库，并打上版本标签。

典型的 CI 管道配置体现了这一检查流程：

# .gitlab-ci.yml（示例片段）
stages:
  - code_merge
  - unit_test
  - integration_test
  - security_scan
  - artifact_push

variables:
  COVERAGE_THRESHOLD: 80

unit_test_job:
  stage: unit_test
  script:
    - mvn clean verify
    - mvn jacoco:report
  coverage: '/Total.*?([0-9]{1,3})%/'

security_scan_job:
  stage: security_scan
  script:
    - trivy image --severity CRITICAL,HIGH --exit-code 1 $CI_APPLICATION_REPOSITORY:$CI_COMMIT_SHA

输入输出物

责任边界

• 开发工程师：保证代码质量、单元测试覆盖率达到标准、修复阻断性问题。
• 测试工程师：设计集成测试场景、维护测试环境稳定性、确认测试结果。
• 安全工程师：维护扫描规则基线、对漏洞进行定级与误报确认、推动高危漏洞修复。
• 发布经理 / 系统管理员：审批合并请求、监控管道运行状态、触发异常处理流程。

记录材料

• Git 提交记录：合 master/release 分支的 Merge Commit。
• CI 管道控制台输出：各 Job 的实时日志与产物（如 `test-results.xml`）。
• 测试报告：单元测试和集成测试的全量通过/失败详情。
• 安全扫描报告：SonarQube/Snyk/Trivy 导出的 PDF/JSON 报告，含漏洞分布与修复建议。

异常处理

验收标准

灰度发布操作启动前，必须逐项确认以下验收条目全部通过：