部署流水线
§1摘要与结论
别名：deployment pipeline、构建流水线、交付流水线、cd pipeline | 英文：Deployment Pipeline | 类型：方法 / process
§2局部关系图
§3原理 · 为什么
交付的置信度不是一次判定，而是可以逐级累积的。把交付拆成多个阶段，让每个阶段回答一个更接近生产的可行性问题，就能在最早的阶段以最低代价拦截失败，而不是等到生产环境才暴露问题。流水线的价值还在于它提供了一个共享、可见、可审计的通道：所有人都能看到某次变更走到了哪一步、卡在哪里、被什么条件拦住，从而减少对个人记忆与口头交接的依赖。它把发布从一个由经验驱动的手工事件，变成一条确定性的自动链路。其背后的经济逻辑很直接：失败越早被发现，修复的代价就越低，因此阶段顺序应按失败代价递增来安排，把廉价而快速的检查放在最前面，把昂贵或需要人工判断的验证放在后面。流水线由此也成为团队对发布质量达成一致共识的载体，把隐含的验收标准显式化，使交付过程对所有人透明。
§4机制 · 如何运作
流水线通常从编译开始，产出后续阶段共享的二进制制品；后续阶段可以包含自动化测试、并行验证、人工检查与授权门，而把制品部署到生产通常是最后阶段。核心纪律是制品只构建一次，之后各环境只是把同一制品逐级提升并重新注入配置，因此每个阶段验证的都是同一个交付对象，而不是各自重新构建出的近似物。每个阶段以明确的通过判据决定是否推进，失败即停止并反馈给触发者。流水线同时承担协作与审计职责：它记录每次变更经过的阶段、每阶段的结果与执行者，为回溯问题与治理交付提供依据。这样，流水线不仅是自动化工具链，也是团队对发布质量与责任边界的共同契约，使谁在何时让什么变更推进到哪一步都有据可查。流水线的质量取决于阶段的判据是否真实反映生产风险：性能、安全与可用性等会导致生产问题的问题应在相应阶段被检出，而不是留到上线后暴露。每个阶段的失败都应给出可操作的反馈，使触发者能迅速定位并修复，而不是在漫长等待后收到一个笼统的失败结论。
§5工程 · 怎么落地
实践中应先按失败代价递增排列阶段，把快速的静态检查与单元测试前置，把昂贵或需要人工判断的验证后置，避免为明显不合格的变更浪费后续资源与时间。坚持同一制品贯穿各环境，环境差异只在配置，为此需要配置外置与制品仓库作为配套能力，否则环境间仍会漂移。为流水线保留协作与审计轨迹，使每次发布都可被追溯。如果交付流程本身复杂而脆弱，应先把它重构为稳定可部署的状态再施加自动化，否则只会得到自动化的脆弱流程，问题被放大而非消除。对于无法自动判定的变更，可以设置人工门，但要明确判据与责任人，避免人工门退化为橡皮图章。此外应控制流水线自身的执行时长与稳定性，让开发者愿意等待而非绕过它，并定期清理已失去价值的阶段。工程上还应把流水线本身视为受管资产：其定义纳入版本控制并接受评审，使之可复现、可回滚；对关键阶段的耗时与失败率做度量，识别瓶颈与不稳定源。对需要人工授权的阶段，应明确授权者、判据与时限，并把授权记录纳入审计轨迹。
§6权衡卡
阶段越多，反馈回路越长、维护成本越高，团队可能因等待而另辟绕过通道，反而削弱流水线的权威。
因此流水线的设计既要覆盖关键风险，也要控制阶段数量与执行成本，并保持可理解与可维护，使其真正可持续运行，而不是成为交付路上的瓶颈。
反例之一是让每个环境各自重新构建，表面上是同一套源码，实际上测试对象与上生产的对象并不相同，使流水线累积的置信度名不副实。
反例之二是在脆弱、不稳定的流程上直接叠加自动化，把原有的混乱固化下来。
反例之三是把流水线做成无人理解的黑盒，一旦关键阶段失败便无人能修。
- 只构建一次要求配套的制品管理与配置外置，否则环境之间仍会漂移。
- 对于难以自动验证的变更必须依赖人工判断，而人工门既慢又容易流于形式。
- 另一处张力是自动化与人工判断的边界：把所有判断都自动化可能放过需要经验识别的问题，而保留过多人工门又会拖慢反馈。
- 合理做法是把可机械判定的部分自动化，把需要权衡的部分集中到少数明确的决策点，并持续依据数据调整二者比例，使流水线既可信又高效。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8案例带
插件 DAG RC5→RC7 升级
一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§9信源与核验
核验结论：应只构建一次同一制品并逐环境提升；各环境重新构建会使测试对象与生产对象不一致，破坏流水线的置信度累积 [VEN-020]
§10原始关系清单
展开：本节点的全部原始关系边（5 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依据推导 | → ESS-J-01 | 构建发布运行分离 E-524 | 部署流水线依据构建发布运行分离 |
| 实现 | ← TEC-J-05 | 部署自动化 E-839 | 部署步骤脚本化与自动执行 |
| 实现 | ← TEC-J-06 | 部署流水线工具化 E-841 | 多阶段制品晋级即部署流水线 |
| 前置依赖 | ← MTH-J-04 | 配置外置与显式化 E-533 | 配置外置是流水线逐环境提升同一制品的前提 |
| 细化 | → MTH-J-02 | 发布工程 E-529 | 部署流水线是发布工程的落地机制 |