第 22 章 CI/CD：从代码提交到自动上线
副题：流水线——把"人跑流程"变成"机器跑流程"
构建体系建起来了：源码能变成制品，制品能部署上线。但新的问题跟着出现：每次发布，构建要人跑、测试要人跑、检查要人做。而人跑的流程，有三个改不掉的毛病：会忘、会跳、会偷懒——赶进度的时候，"这次就不跑全量测试了"是最常见的偷工。于是发布日变成"求神拜佛"的日子：代码大概率是好的，但没人敢打包票。本章就来回答这个问题：CI/CD——把"人跑流程"变成"机器跑流程"：提交代码，自动构建，自动测试，自动检查，自动部署。机器不会忘，机器不会跳，机器不会看日子。
读完本章，要建立三条认知。
- 流水线把反馈前置：提交代码后几分钟就知道红还是绿——问题在合入前被发现，而不是上线后才爆；
- CI 管"自动验证"，CD 管"自动部署"：自动化的程度是一个决策——不是"全自动"才高级，匹配团队节奏的程度才是对的程度；
- 流水线即代码：流水线的配置和源码一起进仓库、一起被评审——协作的轨道，延伸到了交付链路上。
本章的引导词是"流水线"。管道思维这个工具，之前在请求旅程里用过：一个问题端到端地走一遍，找它卡在哪一段。现在把同一个工具搬到交付链路：从提交到上线的每一步都是管道的一段，哪一步红了，就是哪一段卡了——而且流水线自己会告诉你卡在哪，不用人肉排查。
22.1 发布日的"求神拜佛"
上一章建好了构建体系，本章把它放进流水线——构建的自动化形态在这里实现。流水线的最后一站是部署生产，下一章展开。本章的引子，来自上一章结尾那句"人跑的构建会忘、会跳、会偷懒"：阶段 4 的发布流程，构建已经建好，但发布还是手动。发布日的一天，长这样。
早上，先过一遍发布清单——今天要发 5 个功能。开发者手动跑构建：本地打包，传上去，还是手搓部署的形态。中午，发现忘了跑测试——测试体系是现成的，但"人记得跑"这件事不可靠，今天大家赶着发，就跳过了。下午，部署到测试环境，起不来——本地构建的产物和服务器环境不一致，"构建一次、处处运行"还没落地，依然是"谁的电脑构建的谁说了算"。晚上，修好上线，又发现迁移顺序反了——规矩是先迁移再部署，这次反着来，只好回滚。
一天下来，账是这么记的：发布 4 小时，回滚 2 小时，上线 1 小时。更要命的是节奏：发布日没人敢合代码，怕冲突；业务迭代被交付速度卡住——功能早就做好了，发布要等一周一次的发版窗口，那是撑到正式流程建好之前的临时手段。
"求神拜佛"这个词，值得解释一下，因为它是发布日的真实氛围：全团队的精神状态就是祈祷——"别出问题""我改的这块没事吧""上次发布就挂了"。手动发布的不确定性，让发布变成赌博。之前立过一个原则：仔细不是解决方案，机制才是。发布完全一样：靠祈祷的流程，就是靠运气的流程。
赌博心态还会制度化，这就是发布日的另一面：发布冻结。发布日不敢合代码，窗口前干脆冻结——一周七天，四天能合，三天冻结。冻结的本质，是把"随时可交付"让位给"集中发布"。流水线建成之后冻结才会消失：随时可发，等于随时可合。发版窗口本是临时手段，流水线就是来接替它的正式流程——冻结的消失，是流水线给开发节奏的第一个礼物。
晚上复盘，问题只有一个：**为什么每一步都要人记着做？**构建要人跑，测试要人跑，检查要人做，部署要人点。拆开看，人跑流程有三个毛病：会忘——今天忘了测试；会跳——赶时间时跳过检查；会不一致——每个人的"跑法"不一样，本地构建和服务器构建是两回事。之前说过人力会累会跳，也说"主干红了先修"要靠纪律执行——而纪律靠人执行，就会被人跳过。
手动和自动差多少？立一张对比表当账本，每一行都是同一句话：人跑会出错，机器跑不会。
| 环节 | 手动 | 自动 |
|---|---|---|
| 构建 | 谁记得谁跑，产物各不同 | 流水线自动构建，同一环境同一产物 |
| 测试 | 赶时间跳过 | 提交即跑，跳不过去 |
| 检查 | 凭自觉 | lint/契约/安全自动过 |
| 部署 | 谁点谁部署，顺序靠记 | 流程自动部署，顺序写死在流水线 |
读这张表，重点不在"快"。自动化买的不是快，是不赌——把发布日从赌博变回流程。
解法因此只有一句话：把流程交给机器——机器不会忘、不会跳、每次跑得一样。这就是 CI/CD。
22.2 流水线：把流程变成机器
CI，持续集成：每次提交代码，自动触发"构建、测试、检查"——把"大家各自的分支合到一起"这件事的验证自动化。它的价值有两个。反馈速度：提交后几分钟就知道红绿，不用等发布日。失败前置：问题在合入前被发现——评审是合入前的人工把关，CI 就是机器版的评审：人看逻辑，机器跑验证。
CI 名字里的关键词是"持续"。持续的意思是每次提交都集成，不是每周集成一次。集成的频率越高，冲突和问题暴露得越早——小步合入能把大冲突变成小冲突，CI 就是小步合入的验证侧：每一次小步合入，都自动验一次。持续的反面是批量：攒一周一起验证，问题就攒到发布日一起爆——前面那场发布日事故的痛点，正是批量验证。所以 CI 做的事，一句话：把批量验证变成持续验证。
CD，持续交付/持续部署：CI 通过后，自动把制品部署到环境。CD 的价值是可重复性：每次部署走同一套流程。部署不再是"谁点谁部署"，而是"流程自动部署"——这正是"构建一次、处处运行"在部署侧的兑现。
CI/CD 和业务的节奏是什么关系？业务迭代讲的是"三周做出 MVP"，但迭代的节奏取决于交付的节奏：功能做完了，发布要等一周，迭代速度就被卡住。CI/CD 让交付节奏跟上业务节奏，发布从"周更窗口"变成"随时可发"。分工由此清楚：需求侧管"迭代什么"，工程侧管"迭代多快能上线"——交付速度，支撑迭代速度。
CI/CD 也是同一个演进规律的实例。这个规律说过多次：复杂度上升，原方案无法承受，就要换方案。在这里，无法承受的是交付方式——手动发布在 8 人团队面前撞了墙，发布日事故就是撞墙的声音。所以注意，演进不只发生在技术上，也发生在流程上：流程也是"方案"，方案也会"无法承受"，CI/CD 就是交付方式的换代。
持续交付：制品准备好了，随时可部署——"部署按钮"就在那，点不点，人决定。持续部署：没有按钮，提交即上线。两个术语的差别，就是"人工确认"这道闸的有无；术语的差别，本质是自动化程度的差别。
两个词的分工，一句话收束：CI 管"代码对不对"，CD 管"制品上不上线"。CI 失败，挡住合入——主干绿从此有了机器保证，不再只靠人自觉；CD 失败，挡住上线——部署出错，也不把坏版本放给用户。两个闸门，一个在合入前，一个在上线前。
CI 什么时候触发？两种时机，对应协作里两种场景。PR 触发：代码提交到分支时就跑，评审的人能看到"这条 PR 的测试红绿"——测试进 PR 这条纪律的机器版。合入主干触发：合并到主干时再跑一遍，这是主干绿的最后一道闸。两种触发，一个目的：每个环节都有机器验证——PR 时验证改动本身，主干时验证集成结果。
把 CI/CD 的每一步串成一条自动链路，就是流水线：提交、构建、测试、检查、部署。排查方法里有个管道思维——一个问题端到端走一遍，找它卡在哪一段——流水线就是这个思维的工程版：哪一步红了，就是哪一段卡了，而且是机器自动告诉你，不用人肉排查。
放到全书地图上看，流水线的位置就清楚了。地图上有三条线：业务线回答"做什么"，技术线回答"怎么跑通"，工程线回答"怎么让能跑的代码变成能一直跑的产品"。前面所有的积累——请求走通、又快又稳、安全可靠、构建体系——到本章被串成一条自动的交付通道。可以说，三条线在这一章开始合流；后面的部署、高可用、可观测，继续把工程线走完。
最后一个接口问题：CD 的"部署"，部署到哪？答案是跟着阶段走的：测试环境自动部署，生产环境确认后部署。而"部署到哪台机器、怎么部署"，属于环境管理的范畴，是下一章的内容。流水线上"部署"这一步，就是下一章的入口——两章的接口，在这里。
22.3 流水线的阶段：最快失败点
一条完整的流水线长什么样？把前面建好的验证全部串进来。先交代形态：流水线有两种落地方式，先混个脸熟。一种是平台托管——GitHub Actions、GitLab CI 一类，配置写进仓库，平台负责执行；一种是自建——自己搭 CI 服务器，控制力强，但运维成本高。这个阶段选平台托管：团队没有精力养一套自建系统，复杂度预算的原则在此适用——和当年选云厂商 CDN 是同一个决策逻辑。形态不同，机制相同：流水线即代码，提交触发，步骤串联，换平台只是换配置语法——机制学会了，换工具只是换 API。
提交代码（推分支/合入主干）
→ ① 构建（源码→制品；lockfile 校验——"照单安装"是第一条检查）
→ ② 单元测试（快，毫秒级，几千条）
→ ③ 集成测试（真环境：契约/越权/事务）
→ ④ 检查（lint + 契约校验 + 恶意输入测试）
→ ⑤ 部署测试环境（制品自动上测试环境）
→ ⑥ 测试环境验证（E2E + 手动走查联调清单）
→ ⑦ 人工确认（生产部署的"人"的关卡）
→ ⑧ 部署生产（部署环节的展开）
八步的出处列一遍，可以看出流水线没有一步是新知识。构建，来自构建体系；单元测试，金字塔的底座；集成测试，金字塔的中层——契约、越权、事务；检查，是 lint、契约校验、恶意输入测试三件事的合成；部署测试环境，是部署环节的先头部队；测试环境验证，是端到端测试加手动走查；人工确认，是自动化程度决策里留下的那道闸；部署生产，归部署环节展开。八步，每一步都有出处。流水线不是新知识，是验证体系的总装——把散在各处的验证，串成一条自动链。
总装也要讲装配顺序，核心原则叫最快失败点：便宜的检查先跑，贵的验证后跑。lint 秒级，单元毫秒级，构建分钟级，端到端分钟级往上。理由一句话：失败越早发现，修复成本越低。lint 挂了，10 秒就知道；E2E 挂了，20 分钟才知道——同一个问题，早发现在流水线前端，省下的就是这 20 分钟。这个原则和测试金字塔是同一个逻辑的两面：金字塔说"单元要最多"，流水线说"单元要最先"——便宜的先上。
顺序还有一个讲究：验证之间有依赖关系。构建不过，测试无从谈起；单元不过，集成没有基础；集成不过，端到端跑的一定是坏的。所以流水线的阶段顺序，就是验证的依赖顺序——前一步是后一步的前提，顺序反了，后面全白跑。
每一步红了怎么办？三条机制。第一，失败即停：流水线红了，后面的步骤不再执行——单元挂了还跑端到端，纯属浪费资源和时间。第二，失败要通知：红的那一刻，团队频道要响，红要让人看见，这是可见性，后面展开。第三，修复优先：红了先修，别继续开发——"主干红了先修"的流水线版。
红在哪一步，还自带诊断信息。构建红了，是依赖或代码问题；单元红了，是业务规则被破坏；集成红了，是模块合起来的问题——契约、权限、事务；检查红了，是质量或安全的门没过；部署和验证红了，是部署或环境的问题。流水线把"发布日求神拜佛"，变成"哪一步红了看哪一步"。
这正是排查方法论在交付链上的收束。旅程排查法有三问：断在哪一段，卡在哪一层，数据在哪个环节出问题。流水线红了，回答的就是交付链上的"断在哪一段"——不用从头查，看红色停在哪一格。"找卡在哪一段"这个思维，从请求旅程延伸到交付链：理解了一条管道，就理解了所有管道，这句话在这里第二次兑现。
最后给三个数字，度量流水线健不健康。通过率：绿的占比，长期低于 90%，说明测试在跟代码较劲，而不是保护代码。时长：提交到全绿的时间，太长说明反馈慢，瓶颈多半在构建或测试的时长。红灯时长：红着不修的时间有多长。三个数字，对应信任、速度、纪律三个维度——"命中率是体温计"的思路，在流水线上换成了这三个读数。
22.4 反馈速度与失败前置
流水线有两个价值：
第一个价值，反馈速度：提交代码后几分钟就知道红绿。开发过程中，每一次提交都有反馈——测试的反馈原则本来就有一条：反馈越快，人用得越频繁，而流水线把反馈变成了每次提交都自动发生。发布日不再是唯一知道红绿的时机，反馈从"发布日"前置到了"提交时"。
这个前置对开发体验的改变，值得补一笔，因为这是"为什么要 CI"最直接的感受。没有 CI 时，改完代码心里没底："我改了这块，别的影响没影响？"——这是改 A 崩 B 的恐惧。有了 CI，提交后几分钟，全量测试给出回答：没影响。当年说过"几千个规则在几秒内替你确认没改坏"，CI 让这个确认每次提交都有。一句话：CI 把"改完心里没底"变成"改完有机器背书"。
反馈要快，还得知道快不快，这就接上度量思维。性能优化讲过一个原则：先度量，再优化——交付也一样。先度量"提交到全绿要多久"，才知道流水线慢不慢；有了这个数字，"慢在哪一步"一目了然：是构建慢，还是测试慢？前面说过构建时长常常是流水线的瓶颈，度量让瓶颈从猜测变成数字。这是度量思维在交付链上的第二次应用：第一次用在性能上，第二次用在交付上。
第二个价值，失败前置。第一层，问题在合入前被发现：CI 挡住红的主干。注意这里的质变——原来"主干红了先修"是一条靠人自觉的纪律，现在是"红了根本合不进去"。人保证升级为机器保证，CI 的登场理由就在这句升级里。第二层，问题在上线前被发现：CD 挡住坏制品，部署出错不把坏版本放给用户。
"前置"的这两层，正好对应 CI 和 CD 的分工。合入前的前置属于 CI：问题不出现在主干上——红着的主干上继续开分支，等于在坏地基上盖楼，机器版的前置让坏地基无法产生。上线前的前置属于 CD：问题不出现在用户面前，测试环境全绿才走到生产。两层前置，各守一个目标：主干绿，生产稳。
那流水线红了怎么办？行为准则一条：红了是第一优先级的修复。红绿灯不再是谁记得谁修，而是机器亮给全团队看。红灯的可见性由此成立：流水线状态是团队频道里的常驻信息，谁都能看到红绿——"红了大家都知道"，正是 CI 威慑力的来源。
红灯还有一个指标：停留时间。红灯挂多久，等于团队对 CI 的信任度还剩多少。红灯挂一天没人修，说明团队已经开始无视红灯——测试红了被当成"偶发"，狼来了的效应就开始了。所以红灯的处置时长要短，当天修好是标准。红灯时长，是 CI 的体温计。修红灯之前还有一步判断：先归因，再动手。是代码问题——测试该红，按 bug 处理；还是流水线问题——环境或依赖的问题，按构建事故处理。修红灯和修 bug 是两件事，先分清再动手。
最后把流水线放进测试体系里看它兑现了什么。单元、集成、端到端测试，按最快失败点的顺序在流水线里自动跑；恶意输入测试也进来了——安全测试每次上线前跑，此前立过的规矩在此落地；契约校验同样进了流水线：接口的响应格式和契约不一致，机器直接报错——契约本来就是机器可读的格式，正该由机器来校验。
测试是承诺的代码形态；流水线是承诺的自动执行。红灯从"人盯着"变成"机器自动亮"，承诺从"写了"变成"生效"。
22.5 流水线即代码
流水线本身是一套配置：哪几步、什么顺序、什么触发条件。"构建配置也是代码"这条规矩，推广到流水线就是流水线即代码——流水线的定义写进仓库，.github/workflows 一类，和源码一起版本管理。
先拆开这套配置看。"什么时候跑"和"跑什么"一样，都是写进代码的配置。触发条件有几种：推分支时触发，给 PR 做验证；合入主干时触发，做集成验证；定时触发，比如每晚跑一次全量检查——性能巡检的思路在流水线上的版本；手动触发，比如发布日人工确认后的那次部署。四种时机，全是配置项。
再看流水线与环境的关系。流水线是"环境之间的搬运工"：构建和单元测试跑在隔离的构建机上，集成测试连的是测试库，端到端测试走完整的测试环境，最后一步才把制品搬进生产。环境分层——本地、测试、生产——在流水线里变成了阶段之间的传递，每一站用什么环境，流水线负责对接。
既然流水线是代码，就有一个怎么管的问题，两种形态摆在面前。一种是界面配置：在 CI 平台的网页上把流水线点出来，方便，但不可追溯——谁改的、什么时候改的，没有记录。另一种是代码配置：流水线定义进仓库，可追溯、可评审、可回滚。这个阶段的团队选代码配置，理由还是账本思维：不可追溯的配置，等于不可管理的配置——流水线是团队的代码，就该按代码管。
按代码管，具体管什么？流水线配置进仓库，意味着它走 PR、被评审，和源码、测试一起提交。改流水线是改代码，不是运维悄悄改——是团队评审着改。由此，流水线的变更可追溯：谁改的、为什么改，提交纪律管着；流水线配置错了，可以指回上一个版本——制品思维用在了流水线自己身上。不止如此，流水线自己也要被验证：改完流水线，跑一次，看提交能不能从头走到部署——这就是它的验收标准，正如构建的验收是"产物能启动"。
放回到流程建设的路线图上看，这一步也有坐标。8 人团队的流程清单分四步：PR 加评审、测试进 PR、CI、部署流程。现在前三个全部到位，流水线就是第三步的落地——清单上只剩部署流程留给下一章。流程跟着事故和规模长出来的那张路线图，正在按图施工，本章是第三站。
最后把"构建一次、处处运行"在流水线里钉死。这条口号在流水线里是一条设计原则：构建阶段只出现一次，后面的所有阶段用同一个制品——部署测试用它，部署生产也用它，绝不每个环境重新构建一次。重新构建，产物就可能不同，可复现就破了。所以流水线的第一段永远是构建，之后全是"用制品"，"一次"两个字，流水线负责兑现。
22.6 自动化程度的决策：全自动还是半自动
CD 的自动化程度，不是"全自动才高级"，这个问题值得应用一遍决策流程。
① 业务目标：发布要快——业务迭代不能被交付卡住；也要稳——坏版本不能伤到用户。② 业务约束：阶段 4 团队 8 人，发布频率是周更，测试体系刚建全，部署环境还是单服务器，高可用和多机部署是后面的事。③ 技术问题：自动化走到哪一步为止？④ 候选：A，全自动，连生产部署也自动；B，半自动，测试环境自动，生产保留人工确认；C，手动为主，流水线只做检查，部署全手动。⑤ 评价维度：速度——发布多快；风险——坏版本的影响面；信任——自动化能被信任到什么程度，这取决于测试覆盖率和部署机制的成熟度。
先把候选 B 里"人工确认"的位置讲清楚，因为它是"人留在该决策的地方"的物理形态。它落在流水线的第七步：端到端测试之后、部署生产之前。机器验证全部跑完，人做最后判断，然后才部署。半自动的形态就是这句话：机器先跑完，人再拍板。而机器验证是人的依据，不是人的替代——自动化消灭的是重复劳动，留下来的是判断，第七步就是那个判断的位置。
⑥ 打分：A 在阶段 4 是风险大于收益——生产自动部署，意味着"测试没覆盖到的 bug 直接上线"。测试体系刚建全还不满一年，回滚、蓝绿这些部署机制还没影子，信任这个维度撑不起全自动。C 则是一夜回到发布日事故——痛点原样重现。B 是均衡：测试环境自动部署，高频、低风险；生产保留人工确认，低频、高风险，确认的时机是看流水线全绿，再把发布清单过一遍。
生产保留人工确认，就要配一个动作：部署失败的处置流程。线上出了问题，先回滚——制品指回上一个版本——再排查。这里立一条认知：敢部署的前提是能回滚。所以人工确认这一步，一半是确认"能发"，另一半是确认"能回"——回滚方案没想好，这个确认就不算做过。
⑦ 选择：B，半自动 CD。⑧ 收益：发布从"发布日"变成"随时"——测试环境自动，生产一键确认；失败前置——CI 挡合入，CD 挡上线。代价也登记在账上，九步的"代价"一步不能省。流水线跑一次要资源：构建机的时间、平台的额度，跑得越多花得越多。流水线红了要人修，这是持续的维护成本。结论是：CI 的成本是持续的，收益也是持续的——每次提交省下的手动时间，乘以提交次数。提交多，CI 划算；提交少，CI 是负担。复杂度预算的原则在此又一次适用。
半自动里"自动的那一半"，还藏着一笔收益，值得补记。测试环境自动部署，意味着测试环境永远跑着最新代码——产品和测试随时能看到最新版，不用等谁手动部署。验证从"发布日集中进行"变成"每天随时进行"：测试和联调，都在最新代码上跑。彩排的比喻在这里兑现到字面：彩排自动进行。
⑨ 代价与演进：代价是生产部署仍有人工步骤，速度比全自动慢一点。演进条件记三条：测试覆盖率稳定、部署机制成熟（回滚、蓝绿）、发布频率再涨——到了日更的节奏，再评估全自动。
照例，决策记录又添一行：CD 等于半自动，生产人工确认；演进条件是测试成熟、部署机制成熟、发布频率再涨。这个决策模型，至此覆盖了交付领域。
还有两个配套问题，各说一段。第一个，CI 自己的自动化也有阶段：先做检查类——构建、单元、lint，快，先跑起来；再加验证类——集成、端到端、安全，慢，后加上。CI 的成熟度是渐进的，不是一步到位的。八步流水线不必一次上齐：先上构建、单元、检查三步，再逐步补集成、部署、端到端——先小后大，先快后全，演进规律在流水线内部的又一次实例。
第二个，人工确认不是落后，是决策。这道关卡守的正是"机器判断不了"的地方：发布清单——这次改了哪些接口、影响谁、回滚方案是什么——需要人来判断，机器不知道业务影响。分工一句话：自动化管能验证的，人工管要判断的。已知的东西自动化，未知的东西留给人——上线一个功能的影响，机器测不出来。
人工确认也不是"随便看看"，是"对着清单确认"。确认前过三问：流水线全绿吗？——机器验证过了。发布清单对得上吗？——这次发的是什么，影响哪些接口，就是构建交接的那三项。回滚方案是什么？——出事指回哪个制品，制品的版本号就是坐标。三问全过，点才按下。清单的作用一如既往：把"凭感觉"变成"照单走"。
按下确认之后，流水线还有收尾。部署到生产，健康检查跑一遍——服务活着、依赖连得上——再记下部署状态：现在跑的是哪个版本。这两条记录是后面一切的地基。所以"部署完成"不是流水线的终点，而是运行期的起点——高可用和可观测性，从部署完成那一刻接手。
22.7 CI/CD 的边界与代价
最后立几条边界，防止"CI/CD 万能论"。
边界一：流水线本身要维护。它红了要修——而且修之前要分清，是代码问题还是流水线问题，"构建失败是红灯"这条准则在流水线场景照旧适用。它要进化：测试加了、检查加了，流水线跟着加——流水线不是一次建成的，是跟着事故和规模慢慢长出来的。维护的心态也不该特殊：流水线是团队的代码，走 PR、被评审、可回滚，和业务代码同等待遇。
既然要修，就要会排障。"流水线红了"的处理分两步。第一步分两类：代码问题——测试红了，是业务规则被破坏，按测试失败处理；检查红了，是质量或安全的门没过，按质量问题处理。流水线问题——构建环境变了、依赖装不上、平台故障，按构建事故处理。第二步是判断方法：把失败的步骤在本地跑一遍。本地能跑，是流水线的环境问题；本地也挂，是代码问题。先比对环境、再看代码——排查方法论在流水线场景的复用，不需要新知识。
边界二：自动化不消灭所有人工判断。部署前的人工确认、账目的核对、安全事件的处置，都还得是人。自动化消灭的是重复劳动，留下来的是判断。已知流程交给机器，未知情况留给人类——CI/CD 自动化的正是"已知"的那部分。
边界三：流水线会带来虚假安全感，这是最隐蔽的代价。流水线全绿，不等于发布一定没问题——绿只代表"已覆盖的验证都过了"。测试是对行为的承诺，承诺覆盖不到的角落，绿了也白绿。所以"全绿"的正确读法是：该验的都验了，没验的不保证。部署前那道人工确认，补的正是"没验的"那一块。防线是叠出来的，流水线只是其中一道——它是安全网，不是免死金牌。
再补一段流水线与安全的关系。安全测试进流水线，前面已经兑现；更重要的是，流水线是安全事件的快速通道：安全补丁的发布走"升级 PR、流水线验证、确认上线"这条路，"补丁及时升"从此从口号变成机制——及时两个字，由流水线保证。供应链安全同理：制品要验签，验签的执行点就在构建阶段，构建、签名、部署，链条上每一步都可验证。信任模型在交付链的形态就一句话：每一步可验证、可回滚。
还要诚实地交代一句：不是谁都需要完整的 CD。内部工具和原型——没人用的东西，不值得配发布流程，手动跑一遍构建和检查就够。发布频率极低——一年发两次，手动部署的成本完全扛得住，流程是为高频建的。单人单机项目——最少的流程就是正确流程，1 人的团队连 PR 都可以不要。一句话收束这个边界：CI/CD 是"交付频率乘以团队规模"的函数，频率低、规模小，手动就够；频率高、规模大，流水线是必需品。阶段 4 的团队，恰好走到了"必需品"的临界点。
放到演进的整条路上，CI/CD 的位置也要摆正。交付体系是这么走过来的：手动发布，被发布日事故逼到尽头；半自动流水线，被"人跑会忘、会跳、会不一致"逼出来；再往下，部署机制被回滚和多实例的需求逼出来，高可用被单点故障逼出来。每一次都是同一个剧本：原方案无法承受，新机制接管。所以 CI/CD 不是终点，是交付链演进的一站——后面还有部署和高可用两站。
最后一句话预告。将来系统上了多实例，流水线的部署阶段要从"部署一台"变成"部署 N 台"，蓝绿切换、金丝雀放量，也会变成流水线里的标准步骤。流水线的形态跟着部署形态长——部署复杂了，流水线跟着复杂，循环继续。
22.8 本章对应表
| 业务诉求 | 技术选择 | 为什么 | 代价/取舍 |
|---|---|---|---|
| 发布日求神拜佛（慢/易错） | CI/CD 流水线（人跑→机器跑） | 机器不会忘、不会跳、每次一样 | 流水线本身要维护 |
| 改坏了上线才发现 | CI（反馈速度+失败前置） | 提交后几分钟知道红绿，问题合入前拦下 | 红灯要第一时间修 |
| 部署不一致（谁部署谁说了算） | CD（可重复部署） | 每次部署走同一套流程 | 自动化不消除人工判断 |
| 流水线每一步验证什么 | 阶段设计（最快失败点） | 便宜的检查先跑，失败越早修复越便宜 | 阶段要跟着验证体系长 |
| 流水线怎么管理 | 流水线即代码（进仓库走 PR） | 第 20 章协作轨道：改流水线是改代码 | 流水线配置要评审 |
| 自动化到什么程度 | 九步决策（半自动 CD） | 速度 vs 风险：生产保留人工确认 | 演进条件=测试+部署成熟 |
本章小结
- 把"人跑流程"变成"机器跑流程"：机器不会忘、不会跳、每次跑得一样；
- CI 管"代码对不对"（提交后几分钟知道红绿），CD 管"制品上不上线"（可重复部署）——两个闸门；
- 自动化程度是决策：半自动 CD（生产人工确认）是阶段 4 的答案——自动化消灭重复劳动，把判断留给人；
- 发布日成为历史：反馈从"发布日"前置到"提交时"——下一站，把制品放上服务器。
下一章
流水线建好了：提交代码 → 自动验证 → 自动部署到测试环境 → 人工确认 → 部署生产。但"部署生产"这一步，还藏着最大的问题：服务器从哪来？一台够吗？
本章末尾的"部署生产"，展开就是第 23 章的全部内容：部署、环境与配置——一台服务器够不够？不够怎么办？多实例、容器、发布策略——把制品真正放到用户面前的那一步。