第6章 CI/CD 自动化流水线

从提交到生产

章节导读

CI/CD 流水线是软件交付的「生产线」：代码从提交到生产的每一步——构建、测试、扫描、打包、部署、验证——都在这条线上完成。在平台工程出现之前，流水线的建设是各团队的私事：每个团队自己选工具（Jenkins、GitLab CI、GitHub Actions、自建脚本）、自己写配置、自己踩坑，结果是组织内并存几十种流水线实现，质量参差、安全覆盖率不可控、平台级的度量（部署频率、变更前置时间）无从采集。平台工程对 CI/CD 的根本改变是「流水线的平台化」：把流水线从「每个团队的自建资产」转变为「平台提供的标准服务」——业务团队声明少量参数即可获得一条完整的、符合组织安全与质量标准的、自动接入度量的生产级流水线。

流水线平台化的价值可以从四个视角理解。开发者视角：新服务的流水线从「花三天研究 Jenkinsfile」变成「引用平台模板，填两个参数」，且模板内置的缓存策略、并行化、增量构建让流水线速度天然优于团队自建水平；流水线失败时的错误信息经过平台团队的持续打磨，指向可操作的修复步骤。安全视角：SAST、依赖扫描（SCA）、镜像扫描、密钥泄漏检测、SBOM 生成、镜像签名这些安全步骤在平台模板中默认启用且不可绕过（团队可以添加步骤，但不能删除平台门禁），安全覆盖率从「取决于团队自觉」变成「结构性 100%」；Log4Shell 级别的供应链危机爆发时，平台团队修改一处模板即可为全组织添加缓解检查。SRE/运维视角：所有部署走统一通道，渐进式交付（金丝雀、蓝绿）成为默认而非奢侈品，部署事件的标准化让变更-故障关联分析成为可能（「上周的 P1 事故中 68% 与部署相关，其中未走标准金丝雀的占 90%」）。管理层视角：DORA 四指标的数据采集在流水线层自动完成，无需各团队手工填报，组织级交付效能第一次有了可信的统一数据源。

Netflix 与 Spotify 的实践提供了两个经典参照。Netflix 的交付体系围绕 Spinnaker 构建：应用打包为不可变镜像，部署通过标准化的 pipeline 模板执行（bake → deploy canary → 自动金丝雀分析（Kayenta）→ 逐步全量），其「自动金丝雀分析」用统计方法对比金丝雀实例与基线实例的指标，把「发布决策」从人工观察变为算法判定——这是渐进式交付平台化的巅峰形态。Spotify 的路径则不同：Backstage 门户集成多种 CI 系统（内部有数十种），通过插件把各系统的状态聚合到服务目录实体页面，其平台化重心在「流水线可见性与标准化模板」而非统一执行引擎。两种路径的对比揭示了流水线平台化的第一个关键决策：统一执行引擎（所有团队用同一套 CI 系统 + 平台模板）还是联邦聚合（保留团队工具选择，平台提供模板与聚合视图）？前者一致性最强、度量最完整，但迁移成本高、灵活性受限；后者采纳阻力小，但安全门禁与度量的完整性依赖各系统的集成深度。组织规模小、技术栈统一时选前者；规模大、存量系统多时往往从后者起步，逐步收敛。

流水线即代码（Pipeline as Code）是平台化的技术前提：流水线定义必须是版本化的代码（Jenkinsfile、.gitlab-ci.yml、GitHub Actions workflow、Tekton Pipeline CR），才能被模板化、被引用、被策略校验、被度量采集。平台化的实现机制随工具而异但模式相通：GitHub Actions 的 reusable workflows 与 composite actions、GitLab CI 的 include 与 parent-child pipelines、Jenkins 的 shared libraries、Tekton 的 Pipeline 模板 + 参数化——本质都是「平台团队维护流水线定义，业务团队引用并参数化」。共享流水线模板的设计权衡与黄金路径一脉相承：模板要足够标准（安全步骤不可移除、阶段顺序固定）又要足够灵活（允许团队插入自定义步骤、跳过不适用的可选阶段）；「可扩展点」的设计（pre-build hook、post-deploy hook）决定了模板的适应性，「不可变点」（安全门禁）的坚守决定了模板的治理价值。

渐进式交付（Progressive Delivery）是流水线平台化的高级形态：部署不再是「一次性全量替换」，而是受控的流量迁移过程——金丝雀（1% → 5% → 25% → 100%，每步自动分析指标）、蓝绿（新环境就绪后瞬间切换）、滚动更新（K8s 默认的逐批替换）。Argo Rollouts、Flagger 等工具把渐进式策略声明化，平台把它们封装为流水线模板的部署阶段：业务团队在配置中声明 strategy: canary 与 analysis 阈值，平台处理其余一切。渐进式交付的平台化直接改善 DORA 的变更失败率与恢复时间——金丝雀把故障爆炸半径限制在 1% 流量，自动回滚把恢复时间从「人工发现-诊断-回滚的小时级」压缩到「指标异常-自动回滚的分钟级」。

本章的后续要点将深入：标准流水线的阶段设计、四大流水线工具的模板机制对比、渐进式交付的流水线集成、流水线可观测性（构建时长、失败率、队列等待的度量与优化）、以及流水线平台化的迁移策略（存量 Jenkins 森林如何渐进收敛）。流水线是开发者每天接触最频繁的平台能力，其速度与可靠性直接决定开发者对平台的整体评价——「平台什么都好，就是流水线太慢」是最常见的平台差评，流水线性能优化因此是平台团队的永恒课题。

核心概念

CI/CD
流水线即代码
渐进式交付
Tekton

要点精析

【流水线平台化：从团队自建到平台服务的范式转移】流水线平台化不是「统一 CI 工具」这么简单，而是流水线所有权与责任模型的重构。自建模式下，流水线是业务团队的资产：团队自己编写、调试、优化、维护，流水线的问题（慢、不稳定、配置错误）由团队自己消化；平台的角色至多是「提供 Jenkins 服务器」。平台服务模式下，流水线是平台的产品：平台团队拥有模板的定义、性能、安全与演进，业务团队是消费者——消费接口是「引用 + 参数」，服务质量有 SLA（模板流水线的 P90 时长、失败率），问题升级有通道（流水线基础设施故障由平台团队 on-call 处理）。这个责任转移的价值在规模化时显现：安全团队要求「所有镜像必须扫描」，自建模式下需要推动 200 个团队修改各自的配置（现实执行率可能 60%），平台模式下修改模板一处（执行率立即 100%，因为门禁不可移除）。责任转移的代价是平台团队承担了新的负担：模板必须覆盖足够多的场景（否则团队被迫绕过）、模板性能必须持续优化（否则成为众矢之的）、模板变更必须谨慎管理（一次 breaking change 影响 200 个团队的构建）。平台化程度的光谱设计也重要：不是所有流水线都适合完全平台化——标准 Web 服务适合「全托管模板」（业务团队零流水线代码），特殊场景（ML 训练管道、嵌入式固件构建）适合「半托管」（平台提供基础阶段与安全门禁，团队自定义核心阶段），探索性项目适合「自托管 + 策略校验」（团队完全自定义，但 CI 必须通过平台的策略检查——如镜像扫描步骤存在性验证）。光谱的分层让平台化覆盖最大多数，同时不扼杀长尾的灵活性。

【标准流水线的阶段设计：CI 与 CD 的完整解剖】一条生产级标准流水线包含以下阶段，每个阶段的设计都有明确的工程考量。CI 侧：（1）Checkout & Setup——代码拉取、工具链版本锁定（.tool-versions/asdf 或容器镜像固定）、依赖缓存恢复（缓存键设计：依赖锁文件哈希 + 分支，缓存命中率是流水线速度的第一杠杆）；（2）Build & Unit Test——编译与单元测试并行化（按模块分片）、测试报告与覆盖率采集（上传为 artifacts，供质量门禁与趋势分析）；（3）Static Analysis——lint、SAST（Semgrep/CodeQL）、密钥泄漏检测（gitleaks，扫描历史提交中的凭据）；（4）Dependency Scan——SCA 扫描（Trivy/Grype 扫描依赖 CVE）、许可证合规检查（GPL 污染检测）；（5）Package——容器镜像构建（BuildKit + 层缓存 + 多阶段构建）、镜像扫描、SBOM 生成（SPDX/CycloneDX 格式，供应链审计的基础）、镜像签名（cosign）并推送到受信任 Registry；（6）Quality Gate——聚合前述阶段的信号做通过/失败决策（覆盖率阈值、高危漏洞数、SAST 严重项），门禁规则由平台统一维护。CD 侧：（7）Deploy to Test——自动部署到测试环境 + 冒烟测试；（8）Deploy to Staging——部署预发 + 集成/E2E 测试 + 性能基线对比；（9）Approval Gate——生产部署的批准点（自动条件：变更窗口内 + 所有测试通过 + 无未解决的高危告警；人工条件：高风险变更需要 owner 批准——批准逻辑编码在流水线中而非口头约定）；（10）Progressive Deploy——金丝雀/蓝绿/滚动的渐进式生产部署 + 自动指标分析 + 自动回滚；（11）Post-deploy Verification——部署后健康检查、SLO 燃烧率观察期、部署事件记录（供变更-故障关联分析）。阶段设计的平台原则：安全相关阶段（3、4、5 的扫描与签名）不可跳过不可移除；速度优化（缓存、并行、增量）由平台统一实施；每个阶段输出标准化事件（阶段名、时长、结果）到度量系统。

【流水线即代码：四大工具的模板机制对比】主流 CI 工具的模板化机制各有特色，平台选型时需要理解其能力边界。GitHub Actions：reusable workflows（workflow_call 触发的可复用工作流，支持 inputs/outputs/secrets 传递，可跨仓库引用并锁定版本 tag）+ composite actions（多步骤打包为单个 action）；生态最活跃（marketplace 数万个 action），但 reusable workflow 的嵌套深度与矩阵策略组合有限制，超大组织的模板分发依赖「中心模板仓库 + 各仓库引用」模式。GitLab CI：include 机制（include:project 引用其他项目的 YAML 片段，支持 ref 锁定版本）+ extends（任务级继承与覆盖）+ parent-child pipelines（动态生成子流水线）；include 的组合能力最灵活（多文件合并、变量覆盖），单一平台内体验最完整，适合全栈 GitLab 组织。Jenkins：Shared Libraries（Groovy 编写的 vars/ 步骤函数，如 acmePipeline() 一行调用完整流水线）——表达力最强（图灵完备的 Groovy），但维护成本最高（Groovy expertise 稀缺、库版本管理混乱是常态）、性能最差（master-agent 架构的瓶颈）；存量 Jenkins 组织的现实策略是把 shared library 作为「标准流水线的载体」逐步收敛自定义 Jenkinsfile。Tekton：K8s 原生的流水线引擎（Pipeline/Task/Step 全部是 CRD），平台模板即 Pipeline CR，参数化通过 params，工作区通过 PVC；优势是与 K8s 生态无缝（RBAC、事件、Operator 管理）且无中心 master（每个 PipelineRun 是 Pod），劣势是抽象层级低（写 Tekton YAML 的体感接近写 K8s 清单）、生态工具（UI、触发器）需要组装（Tekton Dashboard + Triggers/EventListeners）。平台化视角的选型建议：GitHub/GitLab SaaS 组织直接用其原生模板机制（集成深度最好）；K8s 中心且需要流水线即平台能力的组织选 Tekton（流水线本身成为可编排的平台资源）；存量 Jenkins 组织用 shared library 收敛 + 新服务引导到目标平台的双轨过渡。无论选哪个，平台模板都应锁定版本发布（业务仓库引用 v2.3 而非 main），模板升级走 PR 机器人推送——与黄金路径的升级机制同构。

【渐进式交付：金丝雀、蓝绿与自动分析】渐进式交付把「部署」从瞬间事件变为受控过程，是降低变更失败率与恢复时间的核心技术。三种策略的机制与适用场景：金丝雀（Canary）——新版本先接收小部分流量（1%-5%），指标健康则逐步扩大直至全量；适合无状态服务与大多数 API，资源开销小（新旧版本共存但金丝雀副本少），关键设计是「流量切分精度」（Service Mesh/Istio 的权重路由或 Ingress 的 canary annotation）与「分析窗口」（每个阶段观察多久——太短漏掉慢热问题如内存泄漏，太长拖慢交付）。蓝绿（Blue/Green）——完整部署新版本环境（绿），验证后瞬间切换全部流量，旧环境（蓝）保留待回滚；适合需要「原子切换」的场景（数据库 schema 不兼容的变更、前端整体替换），代价是双倍资源与数据层兼容设计。滚动更新（Rolling）——K8s Deployment 默认的逐批替换，无流量权重控制，是「最弱的渐进式」；适合低风险变更与内部工具。自动金丝雀分析（Automated Canary Analysis，ACA）是渐进式交付的平台化巅峰：Netflix Kayenta 与 Flagger/Argo Rollouts 的 AnalysisTemplate 用统计方法（Mann-Whitney U 检验等）对比金丝雀与基线的指标（错误率、延迟分位数、资源消耗、自定义业务指标），自动做出 promote/rollback 决策——把「工程师盯着 Grafana 判断」变为「算法判定 + 工程师处理例外」。平台封装 ACA 的设计：模板提供默认的指标集（RED 指标 + 资源指标）与阈值（错误率增幅 > 20% 或 P99 延迟增幅 > 50% 即回滚），业务团队可以添加自定义业务指标（如「订单创建成功率」）；分析失败自动回滚并通知，回滚事件记录到部署历史。ACA 的前提是可观测性数据的标准化——这正是黄金路径默认接入监控的深层原因：没有标准化的指标暴露，自动分析无从谈起。

【流水线与黄金路径：模板化、可定制、可继承的组合设计】流水线模板与黄金路径的关系是「干线与支线」：黄金路径定义服务的完整生命周期实践，流水线是其中「构建-交付」干线的实现。组合设计的三层机制。第一层，继承（inheritance）：业务流水线引用平台模板并继承其全部阶段与门禁——实现上如 GitLab 的 include + extends 或 GitHub 的 workflow_call，业务仓库的流水线文件只有 10-20 行（引用声明 + 参数）。第二层，定制点（customization points）：模板暴露受控的扩展接口——参数化定制（java_version: 21、test_command: "mvn verify -Pintegration"）、钩子定制（pre_build_hook、post_deploy_hook 允许插入自定义步骤，但钩子步骤同样受安全策略约束——钩子里不允许 curl 外部未知脚本）、可选阶段开关（skip_performance_test: true 需要附理由且被审计记录）。第三层，逃生舱口（escape hatch）：极少数场景（特殊硬件构建、遗留系统）允许完全自定义流水线，但必须通过平台的「流水线策略校验」——一个静态检查器验证自定义流水线包含全部必需门禁（镜像扫描步骤存在、签名步骤存在、部署走标准通道），校验通过才能启用生产部署权限。三层的比例健康度是平台成熟度的信号：90% 团队在第一层、8% 在第二层、2% 在第三层是理想分布；如果第三层占比超过 10%，说明模板覆盖不足，平台团队应从逃生舱口的使用模式中提炼新的模板变体（逃生舱口是需求发现机制，不是失败标志）。模板的版本演进遵循「加法自由、减法谨慎」：新增可选阶段随时发布 minor 版本；修改默认值或删除阶段是 major 版本，需要迁移期与 PR 机器人辅助升级。

【流水线的可观测性：度量、瓶颈分析与持续优化】流水线自身是需要可观测性的生产系统——它的用户是全组织开发者，它的 SLO 直接影响数百人的日常效率。核心度量指标分四组。速度组：端到端时长（提交到可部署制品，P50/P90）、各阶段时长分布（哪个阶段是瓶颈）、队列等待时间（runner 容量是否足够）、缓存命中率（依赖缓存、构建缓存、镜像层缓存）。质量组：流水线成功率（总体 + 按失败阶段分解——「测试失败」是正常质量信号，「基础设施错误」是平台问题，两者必须分开统计）、flaky 率（同一 commit 重跑结果不一致的比例——flaky 测试是开发者信任的头号杀手）、平均修复轮次（一次变更需要几轮 push 才能通过）。吞吐组：日构建量、并发峰值、runner 利用率。业务价值组：部署频率（DORA）、变更前置时间（DORA，commit 到生产的时间）、流水线成本（每次构建的计算成本 × 构建量——成本可见性是优化优先级的输入）。瓶颈分析的方法论：（1）阶段级火焰图——把 P90 流水线的各阶段时长可视化，找出占比最大的阶段（常见元凶：依赖下载无缓存、Docker 构建无层缓存、测试串行执行）；（2）队列分析——等待时间占比高说明 runner 池容量或调度策略问题（按队列标签细分：linux-arm runner 排队 10 分钟而 x86 空闲，说明池配置失衡）；（3）flaky 检测——自动识别「重跑即过」的测试并隔离到 quarantine 套件（不阻塞主流水线，单独跟踪修复）。平台优化的典型手段：全局缓存服务（跨仓库共享依赖缓存）、构建加速器（Bazel/BuildKit 远程缓存）、测试智能选择（只跑受变更影响的测试——基于依赖图分析）、runner 弹性伸缩（按队列深度自动扩容）、镜像预热（基础镜像预拉到 runner 本地）。优化成果的度量表达：「平台流水线的 P90 端到端时长从 18 分钟降到 7 分钟」是平台团队最有说服力的成绩单之一。

【案例：Netflix 部署流水线与自动金丝雀分析】Netflix 的交付体系是渐进式交付平台化的行业标杆，其架构演进揭示了几个深刻的设计决策。背景：Netflix 在 AWS 上运行数百个微服务，每天数千次部署，任何人工发布流程都无法支撑这个规模。核心组件：Spinnaker（开源的多云交付平台，Netflix 主导开发）作为统一的部署编排层——所有部署通过 Spinnaker pipeline 执行，pipeline 本身由标准化的模板生成（应用团队声明式配置，平台生成 pipeline JSON）；不可变基础设施——应用打包为 AMI/容器镜像，部署即替换实例，杜绝「登录服务器改配置」；Kayenta（开源的自动金丝雀分析引擎）——金丝雀阶段自动采集 Canary 与 Baseline 的指标（来自 Atlas 监控系统），用 Mann-Whitney U 等非参数统计检验对比分布差异，输出 canary score（0-100），低于阈值自动回滚。设计决策的深层逻辑：（1）为什么自动分析而非人工观察？规模决定——每天数千次部署，人工盯盘不可能，且人工判断在统计上不如算法稳定（人会疲劳、会被确认偏差影响）；（2）为什么非参数检验？生产指标分布通常非正态（长尾、多峰），t-test 类参数方法假设不成立，Mann-Whitney U 只比较分布位置不假设形状；（3）为什么金丝雀指标包含「与基线对比」而非「绝对阈值」？绝对阈值无法处理业务周期性（晚高峰错误率天然升高），相对对比自动适应基线波动。Netflix 模式的平台化启示：自动金丝雀分析的前提是指标标准化（所有服务暴露统一语义的 RED 指标）与元数据完整（Spinnaker 知道每个应用的 owner、tier、SLO）——这些正是黄金路径与服务目录提供的。没有标准化的可观测性接入，ACA 就是空中楼阁；反过来，ACA 的存在让「接入标准监控」从合规要求升级为团队自利（接入才能获得自动发布安全网）——平台能力之间的这种相互强化是成熟平台的标志。

【案例：Spotify 的流水线联邦与 Backstage 集成】Spotify 的路径与 Netflix 相反：不统一执行引擎，而是联邦聚合。历史背景：Spotify 的自治小队文化（Squad 自主选择工具）导致内部并存数十种 CI 系统（Jenkins、Travis、自建、后来又有 GitHub Actions），强行统一的组织成本不可接受。Backstage 的解法：（1）目录实体作为聚合锚点——每个服务在目录中登记，其 CI/CD 状态通过插件（GitHub Actions 插件、Jenkins 插件、Spinnaker 插件）挂载到实体页面，开发者在服务的「主页」看到统一的构建状态、部署历史、CD 环境，无论底层用什么系统；（2）标准化在「约定层」而非「执行层」——Spotify 定义了部署元数据标准（每个部署事件必须包含 service、version、environment、actor、timestamp，通过内部 API 上报），任何 CI 系统只要上报标准事件就获得目录集成、部署追踪与度量采集；（3）黄金路径模板提供「推荐流水线」——新服务默认使用平台维护的 GitHub Actions 模板（覆盖构建、扫描、部署到内部 K8s 平台），存量服务自愿迁移。联邦模式的经验教训：（1）聚合视图的价值超预期——「在一个页面看到我服务的一切」是 Backstage 内部满意度的最大来源，证明统一体验不必以统一工具为前提；（2）标准事件协议是联邦的粘合剂——部署事件、构建事件的标准化让度量（DORA 指标）跨系统可采集，这个协议设计值得任何多 CI 系统组织借鉴；（3）联邦的代价是门禁完整性——无法保证所有 CI 系统都执行了安全扫描，Spotify 的对策是把关键门禁后移到「部署准入」（无论怎么构建的镜像，部署到生产 K8s 时由准入控制器验证签名与扫描结果）——「构建侧尽力而为，部署侧强制兜底」是联邦模式的安全架构精髓。

【流水线安全：供应链攻击的防线设计】CI/CD 流水线是软件供应链的核心环节，也是攻击者的高价值目标——2020-2023 年的重大供应链事件（SolarWinds、Codecov、ua-parser-js、3CX）反复证明：攻破流水线或构建环境，就能把恶意代码注入到下游所有消费者。平台化流水线的安全防线设计分五层。第一层，流水线定义的完整性：模板仓库的写权限严格限制（平台团队 + CODEOWNERS 评审），业务仓库的流水线文件变更触发额外审查（修改 .github/workflows 的 PR 自动请求安全团队 review——流水线文件是「可执行的基础设施」，其变更风险等同于生产配置变更）。第二层，构建环境的隔离：每次构建在一次性容器中执行（无状态 runner，构建后销毁），敏感构建（生产镜像）使用隔离的 runner 池（专用节点、无外网出口、egress 白名单）；第三方 action/插件的使用受策略限制（只允许引用 pin 到 commit SHA 的 action——tag 可以被攻击者移动，SHA 不可变；平台维护「已审查 action 白名单」）。第三层，凭据管理：CI secrets 的最小权限与短生命周期（OIDC 联邦身份替代长期密钥——GitHub Actions 的 id-token: write 直接换取云角色的临时凭证，消灭静态密钥）、secret 的作用域限制（生产部署凭据只在 protected 分支/环境的流水线中可用）、密钥泄漏检测（gitleaks 扫描 + secret scanning 的 push protection）。第四层，制品完整性：SBOM 生成（每个镜像的完整依赖清单，漏洞爆发时秒级定位影响面）、镜像签名（cosign keyless 或组织密钥）、签名验证准入（生产集群的准入控制器验证镜像签名——未签名或签名者不受信的镜像拒绝部署，这是「构建侧失守」的最后防线）。第五层，审计与检测：流水线执行的全量审计日志（谁触发、用了什么 secrets、产出了什么制品、部署到哪里）、异常检测（非工作时间的生产部署、构建时长异常偏离基线——可能是注入的恶意步骤、同一制品被重复部署到异常环境）。五层防线的平台化意义：单个团队几乎不可能正确实现全部五层，平台模板让每个服务「免费」获得企业级供应链安全——这是流水线平台化最硬核的价值主张。

【存量流水线的迁移策略：从 Jenkins 森林到平台模板】大多数组织的现实不是绿地建设，而是存量迁移：几十上百个 Jenkins job、各自为政的 GitLab CI、历史悠久的 shell 脚本部署。迁移策略的四个原则。原则一：新增走新路，存量不强制——所有新服务必须使用平台流水线模板（脚手架默认生成），存量服务自愿迁移；随着服务自然更替（重写、合并、下线），存量比例逐年下降，避免「大爆炸迁移」的组织对抗。原则二：迁移分级——对存量流水线做普查分类：A 类（标准 Web 服务，与模板匹配度高）批量迁移（平台提供迁移工具：解析 Jenkinsfile 提取关键参数，自动生成模板引用配置 + PR 机器人提交）；B 类（有自定义步骤但可映射到模板钩子）半自动迁移（平台工程师结对支持）；C 类（特殊构建：硬件依赖、遗留系统）保留原样但加装「安全兜底」（部署侧准入验证签名与扫描，原则同 Spotify 联邦模式）。原则三：激励而非命令——迁移的价值要让团队可感知：平台流水线的缓存与并行优化让构建快 40%、自动金丝雀让发布更安全、流水线维护责任转移给平台（团队不再半夜修 Jenkins）；迁移完成的服务获得目录中的「platform-certified」徽章与更宽松的变更审批（走标准流水线的部署自动批准，自定义流水线保留人工审批——用流程成本差异制造迁移引力）。原则四：退役有期——Jenkins 类存量系统设定明确的退役时间线（如「18 个月后 Jenkins 只读，24 个月后下线」），时间线公开且坚定，但配套充足的迁移支持资源（办公时间、迁移工具、白手套服务）；没有退役期限的「双轨制」会永久化，维护两套系统的成本吞噬平台团队。迁移进度的度量：模板覆盖率（生产部署中走平台模板的占比）、存量分类消化率、迁移团队的构建时长前后对比——这些指标应每月向管理层汇报。

代码示例

/* 示例 1：GitHub Actions 平台流水线模板——完整的 CI/CD 可复用工作流 */
/* 平台团队维护于 acme/platform-pipelines 仓库，业务仓库以 tag 锁定引用 */
name: standard-service-pipeline
on:
  workflow_call:
    inputs:
      service_name: { required: true, type: string }
      runtime: { required: true, type: string }  /* java21|node20|python312|go122 */
      deploy_strategy: { default: canary, type: string }
      skip_e2e: { default: false, type: boolean }
    secrets:
      deploy_credentials: { required: true }

env:
  REGISTRY: registry.acme.com
  /* 平台统一的缓存键前缀——跨仓库共享依赖缓存 */
  CACHE_SCOPE: platform-v3

jobs:
  detect-changes:
    outputs:
      docs_only: ${{ steps.filter.outputs.docs }}
    steps:
      - uses: actions/checkout@v4
      - uses: dorny/paths-filter@4512585405083f25c027a35db413c2b3b9006d50 /* pin 到 SHA */
        id: filter
        with:
          filters: |
            docs:
              - "**/*.md"
              - "docs/**"

  build-test:
    needs: detect-changes
    if: needs.detect-changes.outputs.docs_only != 'true'
    runs-on: [self-hosted, linux, platform-pool]
    steps:
      - uses: actions/checkout@v4
      - uses: ./.github/actions/setup-runtime
        with: { runtime: ${{ inputs.runtime }} }
      - name: 单元测试与覆盖率
        run: make test COVERAGE_OUT=coverage.xml
      - name: 覆盖率门禁（平台标准: 新代码 >= 80%）
        run: |
          python scripts/coverage_gate.py coverage.xml --threshold 80 --diff-only
      - name: SAST 扫描
        uses: returntocorp/semgrep-action@v1
        with: { config: p/owasp-top-ten }

  security-scan:
    needs: build-test
    runs-on: [self-hosted, linux, platform-pool]
    steps:
      - uses: actions/checkout@v4
      - name: 密钥泄漏检测（含历史提交）
        run: gitleaks detect --source . --redact --exit-code 1
      - name: 依赖漏洞扫描
        run: trivy fs --severity HIGH,CRITICAL --exit-code 1 .

  package-sign:
    needs: security-scan
    runs-on: [self-hosted, linux, isolated-pool] /* 隔离 runner：无外网出口 */
    permissions:
      id-token: write /* OIDC 换取临时签名凭证，无静态密钥 */
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: 构建镜像（BuildKit 层缓存）
        run: |
          docker buildx build --cache-from type=registry,ref=$REGISTRY/${{ inputs.service_name }}:buildcache \
            -t $REGISTRY/${{ inputs.service_name }}:${{ github.sha }} --push .
      - name: 镜像扫描
        run: trivy image --severity CRITICAL --exit-code 1 $REGISTRY/${{ inputs.service_name }}:${{ github.sha }}
      - name: 生成 SBOM
        run: syft $REGISTRY/${{ inputs.service_name }}:${{ github.sha }} -o cyclonedx-json | tee sbom.json
      - name: 签名（keyless）
        run: cosign sign --yes $REGISTRY/${{ inputs.service_name }}:${{ github.sha }}

  deploy-production:
    needs: package-sign
    if: github.ref == 'refs/heads/main'
    runs-on: [self-hosted, linux, platform-pool]
    environment: production /* 环境保护规则: 变更窗口 + 必需审批人 */
    steps:
      - name: 创建 Argo Rollout（金丝雀 5%->25%->50%->100%，自动分析）
        run: |
          argo rollouts set rollout ${{ inputs.service_name }} \
            --image app=$REGISTRY/${{ inputs.service_name }}:${{ github.sha }}
      - name: 记录部署事件（平台度量采集）
        run: |
          curl -X POST https://platform-api.acme.internal/v1/deployments \
            -d '{"service":"${{ inputs.service_name }}","version":"${{ github.sha }}",
                 "actor":"${{ github.actor }}","pipeline":"standard-v3"}'

解释：这份 reusable workflow 是流水线平台化的完整参考实现，几乎每个设计点都对应前文的一个原则。inputs 的极简设计（4 个参数）体现「继承层」的定位：业务仓库的引用只需 service_name 与 runtime，deploy_strategy 与 skip_e2e 有平台默认值——对比业务团队自写的 300 行 Jenkinsfile，认知负担的差距是数量级的。detect-changes 阶段实现「文档变更跳过构建」的智能短路——纯 docs PR 不消耗构建资源，这是平台统一实施后所有团队免费获得的优化；注意 paths-filter action 被 pin 到完整 commit SHA 而非 tag，这是供应链安全的具体实践（tag 可被上游攻击者移动重打，SHA 内容寻址不可变）。runner 标签的分池设计（platform-pool vs isolated-pool）实现构建环境隔离：package-sign 在专用隔离池执行（无外网出口 + egress 白名单），因为只有这个阶段接触签名凭证与生产 Registry 推送权限——爆炸半径最小化。permissions 块的 id-token: write 启用 OIDC 联邦：cosign keyless 签名通过 GitHub 的 OIDC token 向 Sigstore 证明「这个构建确实来自 acme/org 的 main 分支」，全程无静态密钥可泄漏。覆盖率门禁的 --diff-only 参数是「新代码 80%」而非「全仓 80%」——对存量低覆盖率仓库友好，避免门禁成为迁移阻力（渐进式质量提升的策略设计）。environment: production 把生产部署的批准规则（变更窗口、审批人）配置在 GitHub 环境保护中而非流水线代码里——策略与执行分离，安全团队可以独立修改保护规则。最后的部署事件上报是 DORA 度量自动采集的埋点：service/version/actor/pipeline 四元组让平台可以跨全部仓库计算部署频率与前置时间，无需任何团队手工填报。

/* 示例 2：业务仓库的流水线引用——「10 行获得完整流水线」 */
/* 文件: .github/workflows/ci.yml（业务仓库中唯一的流水线文件） */
name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  pipeline:
    uses: acme/platform-pipelines/.github/workflows/standard-service-pipeline.yml@v3.2.1
    with:
      service_name: payments-api
      runtime: java21
    secrets:
      deploy_credentials: ${{ secrets.ARGOCD_TOKEN }}
---
/* 对比：迁移前的自建 Jenkinsfile（节选，实际 287 行） */
/* pipeline { */
/*   agent any */
/*   stages { */
/*     stage("Build") { steps { sh "mvn -B package" } } */
/*     stage("Test") { steps { sh "mvn test" } } */
/*     stage("Docker") { */
/*       steps { */
/*         script { */
/*           docker.build("registry.acme.com/payments-api:${env.BUILD_NUMBER}") */
/*           /* 注意: 无镜像扫描、无 SBOM、无签名、无密钥检测 */ */
/*         } */
/*       } */
/*     } */
/*     stage("Deploy") { */
/*       steps { */
/*         sh "kubectl set image deployment/payments-api app=registry.acme.com/payments-api:${env.BUILD_NUMBER} -n prod" */
/*         /* 注意: 直接 kubectl 全量替换，无金丝雀、无自动回滚、无审计事件 */ */
/*       } */
/*     } */
/*   } */
/* } */

解释：这个「前后对比」示例直观展示了流水线平台化的用户侧价值。迁移后的业务仓库只有一个 14 行的引用文件：uses 指向平台模板仓库的具体版本 tag（v3.2.1——版本锁定保证平台模板的 breaking change 不会突然破坏业务构建，升级是团队显式修改 tag 的决策，通常由平台的 PR 机器人辅助完成）；with 传入两个业务参数；secrets 传递部署凭证。对比迁移前的 287 行 Jenkinsfile，差异不只是行数：旧流水线的注释揭示了自建模式的典型缺陷——无镜像扫描（Log4Shell 类漏洞直接进生产）、无 SBOM（漏洞爆发时无法定位影响面）、无签名（任何能推送 Registry 的人可以替换生产镜像）、无密钥检测（凭据泄漏到 Git 历史无人知晓）、直接 kubectl set image 全量替换（无金丝雀、故障即全量、回滚靠手工）、无部署事件记录（DORA 度量靠猜）。这些缺陷不是团队能力问题，而是激励结构问题：业务团队的目标是交付功能，流水线安全是「无功能的成本」，理性选择就是省略。平台模板把这些「理性省略」的环节变成结构性存在——团队想删也删不掉（安全阶段在模板内部，引用方无法移除）。行数减少的另一层价值是维护责任的转移：模板的缓存优化、新安全步骤、性能改进由平台团队持续投入，业务团队通过版本升级免费获得；旧模式下每个团队要自己跟踪 trivy 的新用法、BuildKit 的缓存语法——200 个团队重复 200 次。迁移的实际工作量：平台提供的迁移工具解析旧 Jenkinsfile，提取服务名与运行时，生成这个引用文件并提 PR，团队评审合并即完成——A 类流水线的迁移成本被压缩到 10 分钟。

/* 示例 3：Argo Rollouts 金丝雀发布——渐进式交付的声明式定义 */
/* 平台黄金路径的部署清单模板：金丝雀 + 自动指标分析 + 自动回滚 */
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payments-api
  labels:
    platform.acme.com/golden-path: api-service-v3
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: payments-api-canary
      stableService: payments-api-stable
      trafficRouting:
        istio:
          virtualServices:
            - name: payments-api-vsvc
              routes: [primary]
      steps:
        - setWeight: 5
        - analysis:
            templates:
              - templateName: platform-standard-analysis
            args:
              - name: service-name
                value: payments-api
        - setWeight: 25
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: platform-standard-analysis
        - setWeight: 50
        - pause: { duration: 10m }
        - analysis:
            templates:
              - templateName: platform-standard-analysis
      analysis:
        unsuccessfulRunLimit: 1   /* 一次分析失败即回滚 */
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: platform-standard-analysis
  namespace: platform-system
spec:
  args:
    - name: service-name
  metrics:
    - name: error-rate
      interval: 60s
      count: 5
      successCondition: result[0] < 0.02
      failureLimit: 1
      provider:
        prometheus:
          address: http://prometheus.observability:9090
          query: |
            sum(rate(http_requests_total{service="{{args.service-name}}",
              variant="canary",code=~"5.."}[2m]))
            /
            sum(rate(http_requests_total{service="{{args.service-name}}",
              variant="canary"}[2m]))
    - name: latency-p99-regression
      interval: 60s
      count: 5
      /* 金丝雀 P99 不得超过稳定版的 1.5 倍——相对比较适应业务周期 */
      successCondition: result[0] < 1.5
      failureLimit: 1
      provider:
        prometheus:
          address: http://prometheus.observability:9090
          query: |
            histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service="{{args.service-name}}",variant="canary"}[2m])) by (le))
            /
            histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service="{{args.service-name}}",variant="stable"}[2m])) by (le))

解释：这份 Argo Rollouts 配置是「自动金丝雀分析平台化」的完整实现，分为策略定义（Rollout）与分析逻辑（AnalysisTemplate）两部分。Rollout 的 canary steps 定义了流量迁移剧本：5% → 分析 → 25% → 暂停 5 分钟 → 分析 → 50% → 暂停 10 分钟 → 分析 → （隐式 100%）。几个设计细节：低权重阶段（5%）立即分析（尽早捕获严重回归），高权重阶段增加暂停时长（给慢热问题如内存泄漏、连接池耗尽暴露时间）；trafficRouting 用 Istio VirtualService 实现精确权重切分（对比无 mesh 的副本数比例切分，5% 流量在 10 副本下无法用副本比例表达——1 个副本就是 10%）；unsuccessfulRunLimit: 1 表示任何一次分析失败立即自动回滚（stable 版本接管全部流量），回滚是 Rollout 控制器的内置行为而非额外配置。AnalysisTemplate 是平台团队维护的共享分析定义（放在 platform-system namespace，所有团队的 Rollout 引用同一模板——分析标准的集中管理）：error-rate 指标用绝对阈值（金丝雀 5xx 率 < 2%），latency-p99-regression 用相对比较（金丝雀 P99 / 稳定版 P99 < 1.5）——两种阈值哲学的组合：错误率有客观的业务底线（2% 来自服务的 SLO），延迟则必须相对比较（晚高峰的绝对延迟天然升高，绝对阈值会误报；与同时段的 stable 版本对比自动消除周期性干扰，这正是 Netflix Kayenta「基线对比」思想的简化版）。interval: 60s × count: 5 表示每分钟采样一次共 5 次，failureLimit: 1 允许的单次失败数——采样多次而非一次是为了对抗指标的瞬时抖动（单次毛刺不触发回滚，持续异常才回滚）。这套模板的前提是黄金路径的监控标准化：http_requests_total 必须带 service 与 variant（canary/stable）标签——variant 标签由平台的 Istio 配置自动注入，业务团队无感知。

/* 示例 4：Tekton 平台流水线——K8s 原生的模板与触发器 */
/* 平台以 CRD 形式发布流水线模板，PipelineRun 由事件触发器自动生成 */
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: platform-standard-ci
  namespace: platform-pipelines
  labels:
    platform.acme.com/template-version: "3.2.1"
spec:
  params:
    - name: git-url
    - name: git-revision
    - name: service-name
    - name: runtime
      default: java21
  workspaces:
    - name: shared-data
    - name: git-credentials
  tasks:
    - name: fetch-source
      taskRef: { name: git-clone, kind: ClusterTask }
      params:
        - { name: url, value: "$(params.git-url)" }
        - { name: revision, value: "$(params.git-revision)" }
      workspaces:
        - { name: output, workspace: shared-data }
    - name: build-and-test
      runAfter: [fetch-source]
      taskRef: { name: runtime-build-test }  /* 平台维护的多语言构建 Task */
      params:
        - { name: runtime, value: "$(params.runtime)" }
      workspaces:
        - { name: source, workspace: shared-data }
    - name: scan-and-package
      runAfter: [build-and-test]
      taskRef: { name: secure-package }  /* trivy + syft + cosign 打包 Task */
      params:
        - { name: service-name, value: "$(params.service-name)" }
        - { name: image-tag, value: "$(params.git-revision)" }
      workspaces:
        - { name: source, workspace: shared-data }
---
/* EventListener: 接收 GitHub webhook，按仓库注解生成 PipelineRun */
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: platform-ci-listener
  namespace: platform-pipelines
spec:
  serviceAccount:
    name: tekton-trigger-sa
  triggers:
    - name: push-to-main
      interceptors:
        - ref:
            name: "cel"
          params:
            - name: filter
              value: "body.ref == 'refs/heads/main'"
      bindings:
        - ref: standard-ci-binding
      template:
        ref: standard-ci-template

解释：Tekton 方案展示了「流水线即 K8s 资源」的平台化路径，与 GitHub Actions 方案形成对照。架构分层：ClusterTask 是平台维护的原子能力（git-clone、runtime-build-test、secure-package——多语言构建逻辑封装在 Task 内部，用参数选择运行时）；Pipeline 把 Task 编排为标准序列并定义参数与工作区接口；业务侧不直接编写 Pipeline，而是由 EventListener + TriggerBinding + TriggerTemplate 三件套自动生成 PipelineRun——GitHub webhook 推送到 EventListener 的 ingress 地址，CEL 拦截器过滤事件（只处理 main 分支 push），binding 把事件字段（仓库 URL、commit SHA）映射到 Pipeline 参数，template 实例化 PipelineRun 提交执行。这个「事件驱动生成」模式的价值：业务团队零流水线代码（连引用文件都不需要——仓库在平台登记时 webhook 自动配置），流水线的一切由平台侧的 CRD 控制；升级平台流水线 = 更新 Pipeline CR 的 template-version 标签，所有后续 PipelineRun 自动使用新版本（对比 GitHub Actions 需要每个仓库改 tag——Tekton 的集中控制力更强，代价是灵活性更低）。workspaces 机制（PVC 或 emptyDir）在 Task 间传递代码与缓存，平台可以为 shared-data 配置带持久缓存的 PVC 模板（依赖缓存跨构建复用）。Tekton 方案的适用判断：组织以 K8s 为中心、需要流水线与其他平台能力深度编排（如流水线步骤直接操作 CRD）、多集群场景（Tekton Pipeline 定义可以随 GitOps 分发到多个集群执行）；反之，SaaS 优先的中小组织用 GitHub/GitLab 原生机制的集成成本更低。混合架构也常见：CI 用 GitHub Actions（开发者体验好），CD 用 Tekton/Argo（K8s 原生部署编排）——平台在两者之间用标准部署事件协议缝合度量。

/* 示例 5：流水线度量采集——DORA 指标的自动化计算 */
/* 平台从部署事件流计算 DORA 四指标，Prometheus 记录规则表达 */
groups:
  - name: dora-metrics
    interval: 5m
    rules:
      /* 部署频率: 每服务每天的生产部署次数 */
      - record: dora:deployment_frequency:daily
        expr: |
          sum by (service) (
            increase(platform_deployment_events_total{environment="production"}[1d])
          )
      /* 变更前置时间: commit 时间戳到生产部署完成的时间差 */
      /* platform_deployment_lead_time_seconds 由部署事件上报时计算 */
      - record: dora:lead_time:p90
        expr: |
          histogram_quantile(0.90,
            sum by (le) (rate(platform_deployment_lead_time_seconds_bucket[7d]))
          )
      /* 变更失败率: 导致事故或回滚的部署占比 */
      - record: dora:change_failure_rate
        expr: |
          sum(increase(platform_deployment_events_total{outcome=~"rollback|incident"}[30d]))
          /
          sum(increase(platform_deployment_events_total{environment="production"}[30d]))
      /* 恢复时间: 事故开始到恢复的时长（事故系统与部署事件关联） */
      - record: dora:mttr:p50
        expr: |
          histogram_quantile(0.50,
            sum by (le) (rate(platform_incident_duration_seconds_bucket[30d]))
          )
      /* 流水线健康: 基础设施失败率（区别于测试失败） */
      - record: pipeline:infra_failure_rate
        expr: |
          sum(rate(pipeline_runs_failed_total{reason="infrastructure"}[7d]))
          /
          sum(rate(pipeline_runs_total[7d]))
      /* 流水线速度: 端到端时长 P90 按运行时分解 */
      - record: pipeline:duration_p90:by_runtime
        expr: |
          histogram_quantile(0.90,
            sum by (le, runtime) (rate(pipeline_duration_seconds_bucket[7d]))
          )
---
/* 部署事件上报的数据模型（平台 API 的 protobuf 风格定义） */
/* message DeploymentEvent { */
/*   string service = 1;          /* 目录实体引用 */ */
/*   string version = 2;          /* git SHA */ */
/*   int64  commit_timestamp = 3; /* 用于计算前置时间 */ */
/*   string environment = 4; */
/*   string actor = 5; */
/*   string pipeline = 6;         /* standard-v3 | custom-jenkins | ... */ */
/*   string outcome = 7;          /* success | rollback | incident */ */
/* } */

解释：DORA 四指标的自动化采集是流水线平台化的「度量红利」——没有统一流水线时，这些指标只能靠季度调查问卷估算（误差大、频率低、无法归因）；平台化后它们成为持续更新的时序数据。指标定义的实现细节值得注意：deployment_frequency 用 increase 函数计算日部署次数，按 service 维度分解后可以聚合到团队与组织级（DORA 报告的「精英/高/中/低」分级基于组织级中位数）；lead_time 的计算依赖 commit_timestamp 字段——部署事件上报时携带原始 commit 的时间戳，前置时间 = 部署完成时间 - commit 时间，这要求流水线模板在构建阶段记录 commit 元数据（自建流水线经常丢失这个信息，导致前置时间无法计算——这是联邦模式下度量完整性的典型缺口）；change_failure_rate 的分子是 outcome 为 rollback 或 incident 的部署——rollback 由 Argo Rollouts 自动上报（金丝雀分析失败的回滚事件），incident 由事故管理系统关联（事故时间窗口内的部署被标记）；30 天窗口的滚动计算平衡了统计稳定性与时效性。pipeline:infra_failure_rate 是平台团队自己的 SLO 指标：把失败按 reason 分类（infrastructure vs test_failure vs config_error）至关重要——测试失败是流水线在正常工作（拦截了坏代码），基础设施失败（runner 崩溃、缓存服务不可用、Registry 超时）才是平台的质量问题；混淆两者会让平台团队为业务代码质量背锅，或让平台故障淹没在正常的测试失败中。duration_p90 按 runtime 分解支持精准优化（java21 的 P90 是 15 分钟而 node20 是 6 分钟——Java 的构建缓存策略需要专项改进）。这套指标的运营方式：平台状态页公开展示组织级 DORA 趋势（透明度驱动改进文化），季度平台评审用 by-service 分解定位落后团队并提供迁移支持（「你的服务还在 custom-jenkins 上，前置时间是组织 P90 的 3 倍，迁移工具已就绪」）。

实验笔记

【实验目标】本实验构建一条「平台标准流水线」的端到端最小实现：从业务仓库的 push 事件触发，经过构建、测试、扫描、打包、部署、金丝雀验证的完整流程，并采集流水线度量。实验强调「平台视角」——你将以平台团队身份构建模板，再以业务团队身份消费模板，体验两种角色的完整循环。预计耗时 6-8 小时，可分三次完成。

【环境准备】kind 集群（3 节点）；ArgoCD（helm 安装）与 Argo Rollouts（helm install argo-rollouts + dashboard 可选）；Tekton Pipeline + Triggers（helm 或 kubectl apply 官方 release YAML）；一个 Git 托管（GitHub 免费账号 + 仓库，或本地 Gitea 容器）；示例应用——推荐使用平台提供的 demo 应用（如 argoproj/rollouts-demo 的蓝绿/金丝雀演示镜像，它内置了 /metrics 端点输出带 color 标签的请求指标），或自己写一个 50 行的 FastAPI 应用（暴露 /healthz 与 prometheus 指标）；Prometheus（kube-prometheus-stack，用于金丝雀分析的指标源）。

【步骤一：部署渐进式交付基础（90 分钟）】在 kind 集群安装 Argo Rollouts，部署 rollouts-demo 应用：先创建普通的 stable/canary Service 对与 Rollout 资源（参考本章代码示例 3 的结构，可简化为 20% → 50% → 100% 三步、无 Istio 用副本比例切流）。手动执行一次金丝雀发布：kubectl argo rollouts set image 更新镜像版本，用 kubectl argo rollouts get rollout --watch（或 dashboard）观察金丝雀 Pod 创建、权重变化、promote 过程；再部署一个「坏版本」（rollouts-demo 提供故意返回 500 的镜像 tag），观察失败路径。记录：金丝雀各阶段的状态转换、回滚触发条件。

【步骤二：配置自动分析（75 分钟）】编写简化版 AnalysisTemplate：查询 Prometheus 中 canary 变体的 5xx 错误率（rollouts-demo 的指标带 color/version 标签，可区分 canary 与 stable），successCondition 设为错误率 < 5%，interval 30s、count 3。把 analysis 步骤插入 Rollout 的 canary steps。验证两个场景：好版本发布 → 分析通过 → 自动 promote 到 100%；坏版本（500 错误镜像）发布 → 分析失败 → 自动回滚到 stable。用 kubectl get analysisrun -o yaml 检查分析详情（每次采样的值、成功条件判定）。这个「自动回滚」演示是渐进式交付价值的核心体验——记录坏版本从发布到完成回滚的总时长（通常 < 3 分钟），对比人工发现-诊断-回滚的典型时长（30-60 分钟）。

【步骤三：构建平台流水线模板（120 分钟）】选择工具路径 A（Tekton，推荐——与步骤一的 K8s 环境同构）：安装 Tekton Pipeline，编写平台 Pipeline（fetch → build（可用 kaniko 构建示例应用镜像）→ trivy 扫描 → 部署（创建/更新 Rollout 的镜像 tag））；用 tkn CLI 或 PipelineRun YAML 手动触发一次完整执行。路径 B（GitHub Actions，若有 GitHub 账号）：编写 reusable workflow（build → test → trivy 扫描 → 通过 ArgoCD/kubectl 更新 Rollout），业务仓库用 10 行引用文件消费（参考代码示例 2）。无论哪条路径，要求：业务仓库中的流水线代码不超过 20 行；扫描步骤不可被业务侧移除（在模板内部）；部署步骤输出标准化的「部署事件」（一个包含 service/version/timestamp/outcome 的 JSON，写入集群 ConfigMap 或发送到 webhook 模拟平台 API）。

【步骤四：端到端串联与度量（90 分钟）】配置自动触发：Tekton 路径用 EventListener + GitHub/Gitea webhook（或 GitLab）实现 push-to-main 自动触发；Actions 路径天然事件驱动。完成端到端验证：修改示例应用代码 → push → 流水线自动执行 → 金丝雀发布 → 自动分析 → promote。然后实现最小度量：把部署事件写入 Prometheus（可用 pushgateway 或简单的 metrics exporter），编写 2 条记录规则（部署频率、流水线时长），在 Grafana 建一个「平台流水线状态」仪表盘（部署次数/天、最近 10 次部署的版本与结果、流水线 P90 时长）。

【检查清单】（1）Rollout 金丝雀发布可手动触发且状态流转正常；（2）坏版本发布被自动分析捕获并在 5 分钟内完成自动回滚；（3）AnalysisRun 的 YAML 中可以看到每次采样的指标值与判定结果；（4）业务仓库流水线代码 ≤20 行且扫描步骤在模板内不可移除；（5）push 到 main 后无需人工干预完成「构建→扫描→金丝雀→promote」全流程；（6）Grafana 仪表盘展示部署频率与流水线时长两个指标；（7）实验记录包含「坏版本回滚总时长」与「人工流程对比」的量化数据。

【进阶挑战】（1）为流水线添加 SBOM 生成（syft）与镜像签名（cosign，kind 环境可用 keyless 或本地密钥），再配置一个 Kyverno verifyImages 策略：拒绝部署未签名镜像——体验「构建侧签名 + 部署侧验证」的供应链闭环；（2）实现「变更窗口」门禁：部署 Task 前检查当前时间是否在允许窗口（如工作日 10:00-16:00），窗口外自动暂停等待批准（Tekton 的 custom task 或 Actions 的 environment 保护）；（3）把金丝雀分析升级为「相对比较」：canary P99 延迟与 stable 的比值 < 1.5（参考代码示例 3 的 latency-p99-regression 查询）；（4）度量扩展：采集「流水线基础设施失败率」并区分 test_failure 与 infrastructure 两类失败原因，为平台 SLO 提供数据。