1. 课程导论：Helm Chart 发布质量门禁的背景、目标与整体架构概览

1.1 为什么需要质量门禁？—— 背景与痛点

在云原生生态中，Helm 已成为 Kubernetes 应用打包与分发的标准工具。然而，随着微服务数量激增、Chart 依赖关系复杂化，传统“手动验证 + 人工审批”的发布模式暴露出严重问题：

• 配置漂移：不同环境（Dev/Staging/Prod）的 values.yaml 差异导致行为不一致。
• 依赖断裂：子 Chart 版本未锁定，升级后引发 API 不兼容。
• 安全漏洞：基础镜像或 Chart 自身依赖包含已知 CVE。
• 模板语法错误：{{ .Values.nonexistent }} 在渲染时静默失败，运行时才暴露。
• 合规缺失：缺少资源配额、Pod 安全策略、网络策略等强制标签。

1.2 课程目标：从“人工把关”到“自动化门禁”

本课程旨在构建一套 自动化测试驱动的质量门禁系统，在 Helm Chart 从开发到上线的每个关键节点插入自动化检查关卡。具体目标包括：

1.3 整体架构概览

门禁系统采用 流水线 + 关卡 的架构模式，将测试阶段串联为一条自动化质量走廊。下图展示了核心组件与数据流：

1.4 关键设计原则

1. 左移测试：越早发现缺陷，修复成本越低。静态检查在 PR 阶段即触发。
2. 幂等性：每个关卡可重复执行，相同输入产生相同输出，便于重试与审计。
3. 并行化：无依赖的关卡（如安全扫描与功能测试）可并行执行，缩短流水线总时长。
4. 可观测性：每个关卡输出结构化报告（JUnit XML / SARIF / JSON），供后续分析。
5. 渐进式采纳：支持从“仅警告”模式逐步过渡到“强制阻断”模式，降低团队抵触。

1.5 技术栈选型