跳到主要内容

第 22 章 CI/CD：从代码提交到自动上线

副题：流水线——把"人跑流程"变成"机器跑流程"

第 21 章构建体系建起来了：源码变成制品，制品可以部署。但新问题出现了：每次发布，构建要人跑、测试要人跑、检查要人做——人跑的流程，会忘、会跳、会偷懒（第 18 章说过"人力会累会跳"）。发布日变成"求神拜佛"的日子。本章回答：CI/CD——把"人跑流程"变成"机器跑流程"：提交代码 → 自动构建 → 自动测试 → 自动检查 → 自动部署。

本章要建立的认知

  1. 流水线把反馈前置：提交代码几分钟后就知道红绿——问题在合入前发现，而不是上线后；
  2. CI（持续集成）管"自动验证"，CD（持续交付）管"自动部署"——自动化程度是决策，不是全自动才高级；
  3. 流水线即代码：流水线配置和源码一起进仓库、走评审——它是第 20 章协作轨道的延伸。

本章的引导词："流水线"——第 8 章说过的"管道思维：找卡在哪一段"，在这里从"请求旅程"延伸到"交付链路"：哪一步红了，就是哪一段卡了（第 22.3 会看到它是怎么自动告诉你的）。

22.1 发布日的"求神拜佛"​

第五部分进度（继续）：21 构建 ✅——本章（22）把构建放进流水线——第 21 章说"CI 是构建的自动化形态"，现在实现它；第 23 章部署是流水线的"最后一站"（部署生产那一步的展开）。

第 21 章结尾说"人跑的构建会忘、会跳、会偷懒"——本章把它变成开头的事故：阶段 4 的发布流程建设，第 21 章建好了构建，但发布还是手动。发布日的一天长这样：

早上：发布清单（第 21 章的"部署清单"）过一遍——今天要发 5 个功能。小明手动跑构建（本地打包，传上去——"手搓部署"形态）；中午：发现忘了跑测试（第 18 章的测试体系在，但"人记得跑"不可靠——今天大家赶着发，跳过了）；下午：部署到测试环境，起不来——本地构建的产物和服务器环境不一致（"构建一次、处处运行"还没落地，还是"谁的电脑构建的谁说了算"）；晚上：修好上线，又发现迁移顺序错了（"先迁移再部署"——这次反了），回滚。

一天下来：发布 4 小时，回滚 2 小时，上线 1 小时——发布日没人敢合代码（怕冲突），业务迭代被交付速度卡住：功能做好了，发布要等一周一次的发版窗口（临时手段）。

"求神拜佛"这个词也解释一下（它是发布日的真实氛围）：发布日全团队的精神状态——祈祷"别出问题"、"我改的这块没事吧"、"上次发布就挂了"——手动发布的不确定性，让发布变成"赌博"（第 17 章说过交易系统"仔细不是解决方案，机制才是"——发布也一样：靠祈祷的流程，就是靠运气的流程）。

发布日的另一面："发布冻结"（它是赌博心态的制度化，一句）：发布日不敢合代码——发布窗口前代码冻结（第 20 章的"发布窗口"临时手段的副作用：一周里 4 天能合，3 天冻结）——冻结的本质：把"随时可交付"让位给"集中发布"——CI/CD 之后，冻结消失（随时可发=随时可合）——"发布冻结"的消失，是流水线给开发节奏的第一个礼物（第 20 章说发布窗口是"撑到正式流程建好的临时手段"——流水线就是那个"正式流程"）。

复盘时的问题：为什么每一步都要人记着做？——构建要人跑、测试要人跑、检查要人做、部署要人点——人跑流程的三个毛病：会忘（今天忘了测试）；会跳（赶时间时跳过检查）；会不一致（每个人的"跑法"不一样，本地构建 vs 服务器）。第 18 章说过"人力会累会跳"——第 20 章说"主干红了先修是纪律，但要靠人执行"——纪律靠人执行，就会被人跳过。

手动流程和自动流程的对比表也立一个（它是本章的"账本"，21.8 对应表的前身）：

环节手动（22.1）自动（本章）
构建谁记得谁跑，产物各不同流水线自动构建，同一环境同一产物
测试赶时间跳过提交即跑，跳不过去
检查凭自觉lint/契约/安全自动过
部署谁点谁部署，顺序靠记流程自动部署，顺序写死在流水线

表格的读法：每一行都是"人跑会出错、机器跑不会"——自动化买的不是"快"，是"不赌"（22.1 说发布日像赌博——自动化把赌博变成流程）。

解法一句话：把流程交给机器——机器不会忘、不会跳、每次跑得一样。这就是 CI/CD。

22.2 流水线：把流程变成机器​

CI/CD 的定义（两个词，先分清）：

CI（Continuous Integration，持续集成）：每次提交代码，自动触发"构建+测试+检查"——集成（大家各自的分支合到一起）的验证自动化。CI 的价值两个：反馈速度（提交后几分钟知道红绿，不用等发布日）；失败前置（问题在合入前发现——第 20 章说"评审是合入前把关"，CI 是"机器版的评审"：人看逻辑，机器跑验证）。

"持续集成"的"持续"是什么意思（它是 CI 名字里的关键词）：每次提交都集成（不是每周集成一次）——集成的频率越高，冲突和问题越早暴露（第 20 章说"小步合入把大冲突变成小冲突"——CI 是"小步合入"的验证侧：每次小步合入都自动验证）；"持续"的反面是"批量"（攒一周一起验证——问题攒到发布日一起爆，正是 22.1 的痛点）——CI 把"批量验证"变成"持续验证"。

CD（Continuous Delivery/Deployment，持续交付/部署）：CI 通过后，自动把制品部署到环境——持续交付（部署到测试环境，生产人工确认后部署）和持续部署（连生产也自动部署）是 CD 的两个程度。CD 的价值：可重复性（每次部署走同一套流程——第 21 章"构建一次、处处运行"的部署侧兑现：部署不是"谁点谁部署"，是"流程自动部署"）。

CI/CD 与第 4 章的关系（它是"业务迭代速度"的工程侧）：第 4 章说"三周 MVP"——业务迭代的节奏，取决于交付的节奏（功能做完了，发布要等一周=迭代速度被卡住，22.1 的痛点）——CI/CD 让交付节奏跟上业务节奏：发布从"周更窗口"变成"随时可发"（22.6 半自动的收益）——第 4 章管"迭代什么"，本章管"迭代多快能上线"（交付速度支撑迭代速度——方案原话）。

CI/CD 与第 2 章演进循环（它是"交付能力跟不上"的又一实例）：第 2 章说"业务复杂度上升→原方案无法承受"——这里"无法承受"的是交付方式（手动发布在 8 人团队扛不住：22.1 的发布日）——CI/CD 是交付方式的演进——第 2 章循环从"技术"延伸到"流程"（不只是换技术，是换交付方式——流程也是"方案"，也会"无法承受"）。

"交付"与"部署"的一字之差（它对应 22.6 的决策）：交付（Delivery）=制品准备好了、随时可部署（"部署按钮"在那，点不点是人决定）；部署（Deployment）=自动放上去了（没有按钮，提交即上线）——"持续交付"和"持续部署"的区别，就是"人工确认"这道闸的有无（22.6 的九步，选的就是这道闸留不留）——术语的差别，是自动化程度的差别。

图22-1 一级#6首现 图稿占位
CI/CD 流程
提交→测试→构建→部署闭环

CI 和 CD 的边界一句话：CI 管"代码对不对"，CD 管"制品上不上线"——CI 失败挡住合入（第 20 章"主干绿"的机器保证），CD 失败挡住上线（部署出错不把坏版本放给用户）——两个闸门，一个在合入前，一个在上线前。

CI 的两种触发时机（它对应第 20 章工作流的两种场景，一句）：PR 触发（提交到分支时跑——评审时能看到"这条 PR 的测试红绿"，"测试进 PR"的机器版）；合入主干触发（合并到主干时跑——主干绿的最后一道闸）——两种触发，一个目的：每个环节都有机器验证（PR 时验证改动，主干时验证集成）。

流水线（pipeline）：把 CI/CD 的每一步串成一条自动链路（提交→构建→测试→检查→部署）——第 8 章说过的"管道思维"在这里的工程版：第 8 章说"找'卡在哪一段'"是排查方法，流水线让"卡在哪一段"变成机器自动告诉你（哪一步红了，就是哪一段卡了）。

流水线与第 1 章地图的关系（它是"工程线"的完整形态）：第 1 章说工程线回答"怎么让能跑的代码变成能一直跑的产品"——流水线就是工程线的"主干道"：第 4-15 章的设计与请求走通（业务线/技术线），第 16-21 章的快对稳防久与构建（质量的积累），第 22 章的流水线把它们串成一条自动的交付通道——第 1 章地图的三条线，在这一章开始合流（第 23 章部署、第 24 章高可用、第 25 章可观测性继续走完工程线）。

CD 的"部署到哪"（它是 CD 与第 23 章的接口，一句）：CD 部署的目标环境跟着阶段走——测试环境（自动）→ 生产环境（确认后）——"部署到哪"是环境管理的范畴：流水线说"部署"，部署章说"部署到哪台机器、怎么部署"——流水线的第 ⑤⑧ 步，是部署章的入口（两章的接口在这里）。

22.3 流水线的阶段：最快失败点​

一条完整的流水线长什么样（图 22-2）？把第 18/19/21 章的验证全部串进来：

流水线的两种形态（先混个脸熟，一句）：平台托管（GitHub Actions/GitLab CI 一类——配置写进仓库，平台负责跑）；自建（自己搭 CI 服务器——控制力强但运维重）——阶段 4 选平台托管（团队没精力自建，第 4 章复杂度预算——和 CDN 选云厂商同一个决策逻辑，第 16 章）；机制是一样的：流水线即代码，提交触发，步骤串联——换平台只是换配置语法（第 9 章"机制学会，换工具只是换 API"）。

提交代码（推分支/合入主干）
  → ① 构建（第 21 章：源码→制品；lockfile 校验——"照单安装"是第一条检查）
  → ② 单元测试（第 18 章：快，毫秒级，几千条）
  → ③ 集成测试（第 18 章：真环境，契约/越权/事务）
  → ④ 检查（lint 第 20 章 + 契约校验第 7 章 + 恶意输入测试第 19 章）
  → ⑤ 部署测试环境（CD：制品自动上测试环境）
  → ⑥ 测试环境验证（E2E 第 18 章 + 手动走查第 15 章联调清单）
  → ⑦ 人工确认（生产部署的"人"的关卡）
  → ⑧ 部署生产（第 23 章展开）
图22-2 新 图稿占位
流水线阶段
各阶段职责与反馈点

图 22-1 与图 22-2 的分工（两张图的关系，一句）：图 22-1（一级#6）是全景（提交→验证→部署的闭环——工程线的总图）；图 22-2 是放大（闭环里的"验证+部署"段展开成八步）——同一个"放大"机制（第 4 章铁律：不断放大同一张地图）在工程线的应用——第 8 章放大旅程图、第 15 章点亮旅程图，第 22 章放大交付图——一级图#6 的第一次出现，就带着它的放大图。

流水线八步的出处（它是"把前面章节的验证串起来"的完整清单）：① 构建=第 21 章；② 单元=第 18 章金字塔底座；③ 集成=第 18 章中层（契约/越权/事务）；④ 检查=第 20 章 lint + 第 7 章契约 + 第 19 章安全测试；⑤ 部署测试环境=部署章（先预告）；⑥ E2E=第 18 章塔尖；⑦ 人工确认=第 22.6；⑧ 部署生产=部署章——八步，每步都有前面章节的出处：流水线不是新知识，是"验证体系的总装"（第 22.5 说"它把前面章节的验证全部串成一条自动链"，这里是清单版）。

流水线设计的核心原则：最快失败点——便宜的检查先跑（lint 秒级、单元毫秒级、构建分钟级），贵的验证后跑（E2E 分钟级）——理由：失败越早发现，修复成本越低（lint 挂了 10 秒知道，E2E 挂了 20 分钟才知道——同样一个问题，早发现省 20 分钟）——"最快失败点"是第 18 章金字塔的流水线版：金字塔说"单元最多"，流水线说"单元最先"——同一个逻辑（便宜的先上）。

"最快失败点"还有一个"顺序"的讲究（它是阶段排序的依据）：验证的依赖关系——构建不过，测试没意义（跑不了）；单元不过，集成没意义（基础规则坏了）；集成不过，E2E 没意义（合起来就是坏的）——流水线的阶段顺序 = 验证的依赖顺序（前一步是后一步的前提——顺序反了，后面全白跑）。

流水线的"每步失败处理"（它是"红了怎么办"的机制化）：失败即停（流水线红了，后面的步骤不跑——省资源也省时间：单元挂了还跑 E2E 是浪费）；失败要通知（红的时刻团队频道响——第 22.4 的可见性）；修复优先（红了先修，别继续开发——"主干红了先修"的流水线版）。

每步红了意味着什么（它是"卡在哪一段"的机器版）：① 红了=依赖/代码问题（第 21 章）；② 红了=业务规则破坏（第 18 章）；③ 红了=合起来的问题（契约/权限/事务）；④ 红了=质量/安全门没过；⑤⑥ 红了=部署/环境问题（部署章）——流水线把"发布日求神拜佛"变成"哪一步红了看哪一步"（第 10 章四段排查的交付链版）。

流水线与第 15 章旅程排查法的呼应（它是排查方法论的收束）：第 15 章说"旅程排查法三问：断在哪一段→卡在哪一层→数据哪个环节"——流水线红了，就是交付链的"断在哪一段"（哪步红了看哪步，不用从头查）——"找卡在哪一段"从请求旅程（第 8-15 章）延伸到交付链（第 21-23 章）——同一套管道思维，两处应用（第 8 章说"理解了一条管道就理解了所有管道"——这句话在这里第二次兑现）。

流水线的度量（"流水线健不健康"的三个数字，一句）：通过率（绿的占比——长期低于 90%，说明测试在跟代码较劲而不是保护它）；时长（提交到全绿的时间——太长=反馈慢，瓶颈在构建/测试时长）；红灯时长（22.4 说过的体温计）——三个数字，对应"信任、速度、纪律"三个维度（第 16 章"命中率是体温计"在 CI 的版本）。

22.4 反馈速度与失败前置​

流水线的两个价值，展开讲（它们是"为什么自动化"的完整答案）：

反馈速度：提交代码后几分钟知道红绿——开发时每次提交都有反馈（第 18 章说"反馈越快用得越频繁"——测试的反馈，流水线把它变成每次提交都有）；发布日不再是"唯一知道红绿的时机"（22.1 的痛点：问题攒到发布日一起爆）——反馈从"发布日"前置到"提交时"。

"反馈前置"对开发体验的改变也补一笔（它是"为什么要 CI"最直接的感受）：没 CI 时——改完代码，心里没底："我改了这块，别的影响没影响？"（第 18 章的"改 A 崩 B"恐惧）；有 CI 时——提交后几分钟，全量测试告诉你"没影响"（第 18 章说"几千个规则在几秒内替你确认没改坏"——CI 让这个"确认"每次提交都有）——CI 把"改完心里没底"变成"改完有机器背书"。

反馈速度与第 16 章"度量"的关系（它是"没有度量是玄学"的交付版）：第 16 章说性能优化"先度量再优化"——交付也先度量："提交到全绿要多久"是交付的度量（22.3 的流水线时长）——没有度量，不知道流水线慢不慢；有了度量，"慢在哪一步"一目了然（构建慢？测试慢？——第 21 章说"构建时长是流水线的瓶颈"，度量让它可见）——第 16 章的度量思维，在交付链的第二次应用（性能度量 + 交付度量）。

失败前置：问题在合入前发现（CI 挡住红的主干——第 20 章"主干绿"的机器保证：不是"红了先修是纪律"，是"红了合不进去"）——"人保证"升级为"机器保证"（第 20 章说"主干绿从人保证升级到机器保证，就是 CI 的登场理由"——现在它登场了）；上线前发现（CD 挡住坏制品——部署出错不把坏版本放给用户）。

"失败前置"的"前置"有两层（它是 CI 和 CD 的分工细节）：合入前（CI：问题不出现在主干上——第 20 章"红着的主干上继续开分支=在坏地基上盖楼"的机器版）；上线前（CD：问题不出现在用户面前——部署前测试环境全绿才到生产）——两层前置，对应"主干绿"和"生产稳"两个目标（第 20 章管前者，部署章管后者）。

"红了"的处理（它是 CI 的行为准则，第 18 章"测试失败可见性"的兑现）：流水线红了，是第一优先级的修复（"主干红了先修"——现在红绿灯是机器亮给全团队的，不是谁记得谁修）——红灯的可见性：流水线状态是团队频道里的常驻信息（谁都能看到红绿）——"红了大家都知道"是 CI 的威慑力来源（第 18 章说过，这里是执行）。

红灯的"停留时间"（它是 CI 健康度的一个指标，一句）：红灯挂多久=团队对 CI 的信任度——红灯挂一天没人修，说明团队已经开始无视红灯（"偶发红的测试最后会被无视——狼来了效应"，第 18 章）——红灯的处置时长要短（当天修好是标准）——"红灯短"和"测试快"一样，是 CI 体系的日常指标（第 16 章"命中率是体温计"，红灯时长是 CI 的体温计）——红灯的修复还要"归因"：是代码问题（测试红了，第 18 章处理）还是流水线问题（环境/依赖，第 21 章处理）——修红灯和修 bug 是两件事，先分清再动手（22.7 的排障方法，这里先立判断）。

CI 与第 18/19 章测试的关系（它是"测试进流水线"的兑现）：第 18 章说"测试失败必须显眼——CI 里红灯"——现在测试真的进了 CI：单元/集成/E2E 在流水线里自动跑（金字塔按最快失败点排序）；第 19 章说"安全测试每次上线前跑（进 CI）"——恶意输入测试也在流水线里（22.3 的 ④ 阶段）；第 7 章的契约校验也进 CI（ch07 说"响应格式和契约不一致，CI 直接报错"——契约是机器可读的，机器校验它）。

流水线与第 18 章测试金字塔的关系（它是"承诺的自动化"）：第 18 章说"测试是承诺的代码形态"——流水线是"承诺的自动执行"：承诺（测试）写好了，流水线让它们每次提交都执行——第 18 章建承诺，本章让承诺自动兑现（红灯从"人盯着"变成"机器自动亮"）。

22.5 流水线即代码​

流水线本身是配置（哪几步、什么顺序、什么触发条件）——"构建配置也是代码"（第 21 章），流水线配置同样：流水线即代码（pipeline as code）——流水线定义写进仓库（.github/workflows 一类），和源码一起版本管理。

流水线的触发条件（它是"即代码"的配置部分，一句）：触发条件也是配置——推分支触发（PR 验证）、合入主干触发（集成验证）、定时触发（每晚跑一次全量，第 16 章性能巡检的流水线版）、手动触发（发布日确认后的部署）——"什么时候跑"和"跑什么"一样，都是写进代码的配置（触发条件是流水线定义的一部分）。

流水线与环境的关系（它是第 15 章环境分层的交付侧，一句）：流水线的各阶段跑在不同环境——构建/单元在流水线环境（隔离的构建机）、集成测试连测试库（第 18 章测试库）、E2E 在测试环境（第 15 章）、部署到生产（第 23 章）——流水线是"环境之间的搬运工"：它把制品从构建环境搬到测试环境再搬到生产——第 15 章的环境分层，在流水线里变成了阶段之间的传递（每一站的环境，流水线负责对接）。

流水线的两种管理形态（"为什么即代码"的对照）：界面配置（在 CI 平台网页上点出来的流水线——方便但不可追溯：谁改的、什么时候改的，没有记录）；代码配置（流水线定义进仓库——可追溯、可评审、可回滚）——阶段 4 选代码配置（第 20 章的账本思维：不可追溯的配置=不可管理的配置——流水线是团队的"代码"，就该按代码管）。

为什么流水线即代码（它是第 20 章协作轨道的兑现）：流水线配置进仓库 = 流水线走 PR = 流水线被评审（代码和测试一起提交——流水线配置也一起提交）——改流水线是改代码（不是运维悄悄改，是团队评审着改）：流水线的变更可追溯（谁改的、为什么改——提交纪律）、可回滚（流水线配置错了，指回上一个版本——制品思维用在流水线自身）。

流水线的"测试"（它自己也要被验证，一句）：改流水线后，跑一次流水线验证它——"流水线能不能跑"是流水线的验收（第 21 章说"构建的验收是产物能启动"，流水线的验收是"提交能走到部署"）。

流水线与第 20 章流程清单的关系（它是"流程清单第三步"的兑现）：第 20 章说 8 人团队的流程清单——第三步是 CI（第 22 章）：现在它落地了——流程清单的前三步（PR→测试进 PR→CI）在阶段 4 全部到位，第四步（部署流程）是部署章——第 20 章画的"流程跟着事故长"的路线图，正在按图施工（第 2 章演进循环的团队版，第 22 章是它的第三站）。

流水线与第 21 章的衔接（构建是流水线第一段）：第 21 章说"CI 里第一步永远是构建"——流水线 = 第 21 章构建 + 第 18 章测试 + 第 19 章安全检查 + 第 7 章契约 + 第 23 章部署——它把前面章节的"验证"全部串成一条自动链（第 22.3 的八步，每一步都有出处）。

"构建一次"在流水线里的执行（第 21 章"同一份源码只构建一次"的伏笔）：流水线让这句话字面成立：构建阶段只出现一次，后面的阶段全部用同一个制品（部署测试用它、部署生产用它——不是每个环境重新构建）——"构建一次"是流水线的设计原则，不是口号（重新构建=可能不同=复现破）。

22.6 自动化程度的决策：全自动还是半自动​

CD 的自动化程度不是"全自动才高级"——走一遍九步（第 5 章模型的第 14 次应用）：

① 业务目标：发布快（业务迭代不被交付卡住）且稳（坏版本不伤用户）；② 业务约束：阶段 4 团队 8 人、发布频率周更（第 20 章说过的节奏）、测试体系刚建全（第 18 章）、部署环境单服务器（部署章才演进）；③ 技术问题：自动化到哪一步？④ 候选：A 全自动（连生产部署都自动）；B 半自动（测试环境自动，生产人工确认）；C 手动为主（流水线只做检查，部署全手动）；⑤ 评价维度：速度（发布多快）、风险（坏版本影响）、信任（自动化能否被信任——测试覆盖率/部署机制成熟度）；人工确认在流水线的位置（它是"人留在该决策的地方"的物理形态，一句）：第 ⑦ 步——它在 E2E 之后、部署生产之前：机器验证全部通过（①-⑥），人做最后判断（⑦），然后才部署（⑧）——"机器先跑完，人再拍板"是半自动的形态（机器验证是人的依据，不是人的替代——第 22.7 说"自动化把重复劳动消灭，把判断留给人"，第 ⑦ 步就是那个"判断"的位置）。

⑥ 打分：A 在阶段 4 风险大于收益——生产自动部署意味着"测试没覆盖到的 bug 直接上线"（第 18 章刚建全的测试还不满一年，部署机制（回滚/蓝绿）还没建）；C 回到 22.1 的痛点；B 均衡——测试环境自动部署（高频、低风险），生产保留人工确认（低频、高风险——人确认的时机：看流水线全绿 + 发布清单过一遍，第 21 章的发布单）；

部署失败的处理（它是"生产保留人工确认"的配套动作，先预告）：部署失败（线上出问题）的处置流程——先回滚（制品指回上一个版本，第 21 章）再排查（第 24 章应急）——"敢部署"的前提是"能回滚"（部署机制的回滚能力，是部署章的内容——本章先立认知：半自动部署的"人工确认"，一半是确认"能发"，一半是确认"能回"）；⑦ 选择：B（半自动 CD）；⑧ 收益：发布从"发布日"变成"随时"（测试环境自动、生产一键确认），失败前置（CI 挡合入、CD 挡上线）；CI 的成本也登记在账（九步的"代价"不能省）：流水线跑一次要资源（构建机时间/平台额度——跑得越多花得越多）；流水线红了要人修（22.7 代价一）——CI 的成本是"持续的"，收益也是"持续的"（每次提交省下的手动时间 × 提交次数——提交多，CI 划算；提交少，CI 是负担——第 4 章复杂度预算的又一处应用）；测试环境自动部署的"隐藏收益"也补一笔（它是半自动里"自动的那半"的价值）：测试环境永远是最新代码——产品/测试随时看到最新版（第 15 章"测试环境是生产的彩排"——彩排自动进行，不用等谁手动部署）——"测试环境自动"让验证从"发布日集中"变成"每天进行"（第 18 章测试、第 15 章联调，都在最新代码上跑）；⑨ 代价与演进：生产部署仍有人工步骤（速度比全自动慢一点）；演进条件：测试覆盖率稳定 + 部署机制成熟（回滚/蓝绿）+ 发布频率再涨（日更），再评估全自动（生产自动部署）。

决策记录又添一行：CD=半自动（生产人工确认），演进条件=测试成熟+部署机制成熟+发布频率再涨。第 14 次填写——从第 12 章的七次到本章的十四次，决策模型覆盖了交付领域。

CI 的自动化程度也有"阶段"（它是 CD 决策的配套，一句）：CI 本身也可以分阶段——先做"检查类 CI"（构建+单元+lint——快，先跑起来）→ 再加"验证类 CI"（集成/E2E/安全——慢，后加上）——CI 的成熟度是渐进的不是一步到位的（第 22.3 的八步，第一步先上①②④，再逐步加③⑤⑥——第 2 章演进循环在 CI 内部的又一次实例：先小后大，先快后全）。

"人工确认"不是落后（它是决策，不是妥协）：人工确认的关卡，是"机器判断不了"的地方——发布清单（第 21 章：这次改了哪些接口、影响谁、回滚方案）需要人判断（机器不知道业务影响）；自动化管"能验证的"，人工管"要判断的"（第 19 章说过"自动化管已知，手动管未知"——部署决策是"未知"的一种：上线这个功能的影响，机器测不出来）。

人工确认的"清单"（它是第 21 章发布单的正式形态，一段够用）：确认前过三问——流水线全绿吗？（机器验证过了）；发布清单对得上吗？（这次发的是什么、影响哪些接口——第 21 章的交接三项）；回滚方案是什么？（出事指回哪个制品——第 21 章制品版本）——三问全过，点确认——人工确认不是"随便看看"，是"对着清单确认"（第 15 章联调清单的发布版：清单把"凭感觉"变成"照单走"）。

确认之后的动作（它是 CD 的最后一环，一句）：部署到生产后，流水线还要"收尾"——健康检查（第 21 章的 /health，部署章展开）、部署状态记录（第 21 章"哪个版本在跑"——第 24 章排障的起点）——"部署完成"不是流水线的终点，是运行期的起点（第 24 章高可用、第 25 章可观测性，从部署完成那一刻接手）。

22.7 CI/CD 的边界与代价​

最后立边界（它防止"CI/CD 万能论"）：

代价一：流水线本身要维护。流水线红了要修（是代码问题还是流水线问题——第 21 章"构建失败是红灯"的流水线版）；流水线要进化（测试加了、检查加了，流水线跟着加——第 22.3 的八步不是一次建成的，是跟着事故长的，第 2 章演进循环）；流水线是团队的"代码"（第 22.5：走 PR、被评审、可回滚——它该和业务代码同等的对待）。

流水线失败的排障（"流水线红了"的具体处理，一段）：先分两类——代码问题（测试红了=业务规则破坏，第 18 章处理；检查红了=质量/安全问题，第 19/20 章处理）和流水线问题（构建环境变了、依赖装不上、平台故障——第 21 章处理）——判断方法：把失败的步骤在本地跑一遍——本地能跑=流水线环境问题；本地也挂=代码问题（第 15 章"先比对环境再看代码"的排查顺序，在流水线场景复用）——流水线排障，用的是本书已有的排查方法论（第 15 章环境排查 + 第 21 章构建排障）。

代价二：自动化不消除所有人工判断。部署确认（22.6）、对账（第 17 章）、安全事件的处置（第 19 章）——自动化把"重复劳动"消灭，把"判断"留给人（第 19 章说"自动化管已知，手动管未知"——CI/CD 是"已知流程"的自动化，未知的判断还是人的）。

代价三：流水线的"虚假安全感"（它是最隐蔽的代价）：流水线全绿 ≠ 发布一定没问题——绿只代表"已覆盖的验证都过了"（第 18 章说过"测试是承诺的测试"——承诺覆盖不到的，绿了也白绿）——"全绿"的正确读法：该验的都验了，没验的不保证（第 22.7 的人工确认，就是补"没验的"那一块）——流水线是安全网，不是免死金牌（第 17 章"防线是叠的"——流水线也是防线之一，不是全部）。

CI/CD 与第 19 章安全的关系（它是"安全是持续过程"的交付侧）：第 19 章说"安全测试进 CI"（22.3 的 ④ 已收）——流水线还是安全事件的"前置防线"：安全补丁的发布走流水线（升级 PR→流水线验证→快速上线——第 21 章说"安全补丁及时升"，流水线让"及时"从口号变成机制）；供应链安全（第 21 章说制品要验签）——流水线的构建阶段就是验签的执行点（构建→签名→部署，链条上的每一步可验证）——安全在交付链的形态：每一步可验证、可回滚（第 19 章的"信任模型"，交付链版）。

边界：什么时候不需要完整 CD（第 4 章复杂度预算在交付上的应用）：内部工具/原型（第 4 章砍掉的验证路径——没人用的东西不需要发布流程）；低频发布（一年发两次，手动部署的成本可以接受——流程是为"高频"建的，第 20 章"流程是团队的函数"）；单机个人项目（第 20 章 1 人团队：最少的流程）——CI/CD 是"交付频率 × 团队规模"的函数：频率低规模小，手动够；频率高规模大，流水线是必需品（阶段 4 正好到了"必需品"的临界点）。

CI/CD 与第 2 章演进循环（它是"原方案无法承受"的交付版）：手动发布（阶段 4 起点，被发布日事故逼出）→ 脚本/半自动（第 21 章构建+第 22 章流水线，被"人跑会忘"逼出）→ 部署机制（被多实例/回滚逼出）→ 第 24 章高可用（被单点故障逼出）——交付体系的每一步，都是第 2 章循环的实例：每次都是"原方案无法承受"，每次都是"新机制解决"——CI/CD 不是终点，是交付链演进的一站（第 24-25 章还有两站）。

流水线与第 24 章的衔接（一句预告）：将来多实例（第 24 章），流水线的部署阶段从"部署一台"变成"部署 N 台"（蓝绿/金丝雀的切换也进流水线）——流水线的形态跟着部署形态长（第 2 章循环：部署复杂了，流水线跟着复杂）。

22.8 本章对应表​

业务诉求技术选择为什么代价/取舍
发布日求神拜佛（慢/易错）CI/CD 流水线（人跑→机器跑）机器不会忘、不会跳、每次一样流水线本身要维护
改坏了上线才发现CI（反馈速度+失败前置）提交后几分钟知道红绿，问题合入前拦下红灯要第一时间修
部署不一致（谁部署谁说了算）CD（可重复部署）每次部署走同一套流程自动化不消除人工判断
流水线每一步验证什么阶段设计（最快失败点）便宜的检查先跑，失败越早修复越便宜阶段要跟着验证体系长
流水线怎么管理流水线即代码（进仓库走 PR）第 20 章协作轨道：改流水线是改代码流水线配置要评审
自动化到什么程度九步决策（半自动 CD）速度 vs 风险：生产保留人工确认演进条件=测试+部署成熟

每一行都在本章正文里有完整论证：发布日在 22.1，定义在 22.2，阶段在 22.3，价值在 22.4，即代码在 22.5，决策在 22.6，边界在 22.7。先看"业务诉求"列——这一章的每一行，都是从发布日那一天里长出来的。

本章对两类读者的收益（与前几章同款）：前端读者——前端构建/测试在流水线里的位置（构建产物上 CDN、E2E 验证页面），是前端交付的日常；后端读者——契约/越权/事务测试进流水线，是后端交付的主场；两类读者共同的收获：交付第一次有了完整的自动链路——"发布日求神拜佛"从阶段 4 的日常变成历史（五阶段故事线的关键事件"发布事故复盘→引入 CI/CD"，本章落地）。

本章与第 18 章的呼应（它是"测试进 CI"的完整闭环）：第 18 章结尾说"测试的进化路径：纸面清单→手工脚本→分层测试→第 22 章的 CI（提交代码自动跑）"——现在第 22 章到了：测试体系的进化路径走完最后一段——第 18 章建承诺，第 22 章让承诺自动兑现（"测试从工具变成流水线的一部分"——第 18 章说"测试的自动化程度跟着团队走，先有测试再谈自动化"，本章就是那个"自动化"）。

本章与第 23 章的边界：本章管"流程怎么自动"（流水线：验证+部署编排）；第 23 章管"部署怎么执行"（服务器/环境/容器/回滚——流水线最后的"部署生产"步骤，展开是第 23 章的全部）——流水线是"剧本"，部署是"舞台"：剧本（22 章）说"部署生产"，舞台（23 章）实现"怎么部署"——两章的交界处，是流水线的第 ⑧ 步。

阶段 4 关键事件落地（五阶段故事线的登记）："发布事故复盘 → 引入 CI/CD"——第 20 章的事故三（发布互相踩）在这里完成复盘闭环：事故 → 发布日痛点（22.1）→ 流水线（本章）→ 发布日成为历史——第 2 章演进循环的完整一轮（事故逼出机制，机制消灭事故）。

本章小结​

流水线速查（第五部分回指本章时翻回这里）：

  1. CI=自动验证（反馈速度+失败前置），CD=自动部署（可重复性）——CI 挡合入，CD 挡上线；
  2. 流水线八步：构建→单元→集成→检查（lint/契约/安全）→部署测试→E2E→人工确认→部署生产；
  3. 最快失败点：便宜的检查先跑——失败越早发现，修复成本越低（金字塔的流水线版）；
  4. 流水线即代码：配置进仓库走 PR——改流水线是改代码（第 20 章轨道）；
  5. 自动化程度：半自动 CD（九步第 14 次应用）——生产保留人工确认，演进条件=测试+部署成熟；
  6. 边界：流水线要维护、自动化不消除判断、内部工具/低频发布不需要完整 CD。 （六条速查对应本章结构：1-2 是"是什么/怎么串"，3 是"设计原则"，4-5 是"管理/决策"，6 是"边界"——第 23 章部署回指本章时重点翻 3（流水线阶段）和 6（自动化程度）。）

流水线与第 21 章速查的对照（它是"构建是流水线第一段"的速查版）：第 21 章速查说"构建一次、处处运行"——本章速查的 ① 就是它（构建在流水线只出现一次）；第 21 章速查说"lockfile 是复现基石"——本章速查的 ① 里就有它（照单安装是第一条检查）——第 21 章建了地基，本章在地基上盖流水线（两章速查对照着读，就是"构建→流水线"的完整图景）。

第五部分进度：21 构建 ✅ 22 CI/CD ✅——还剩 23 部署——发布三段式走完两段：制品做好了（21），自动验证和部署流程串好了（22），最后一段：把制品真正放上服务器（23：部署、环境与配置）。

  • 把"人跑流程"变成"机器跑流程"：机器不会忘、不会跳、每次跑得一样；
  • CI 管"代码对不对"（提交后几分钟知道红绿），CD 管"制品上不上线"（可重复部署）——两个闸门；
  • 自动化程度是决策：半自动 CD（生产人工确认）是阶段 4 的答案——自动化消灭重复劳动，把判断留给人；
  • 发布日成为历史：反馈从"发布日"前置到"提交时"——下一站，把制品放上服务器。

下一章​

流水线建好了：提交代码 → 自动验证 → 自动部署到测试环境 → 人工确认 → 部署生产。但"部署生产"这一步，还藏着最大的问题：服务器从哪来？一台够吗？

第 22 章末尾的"部署生产"，展开就是第 23 章的全部内容：部署、环境与配置——一台服务器够不够？不够怎么办？多实例、容器、发布策略——把制品真正放到用户面前的那一步。

写到这里，第五部分走完两站（21 构建 ✅ 22 CI/CD ✅）；全书进度：第 1-3 章地图、第 4-7 章设计、第 8-15 章走通请求、第 16-20 章快对稳防久、第 21-22 章交付自动化——还剩第 23-28 章：部署、高可用、可观测性、架构演进、业务迭代、成长路径——工程线的最后一段，和第 1 章地图的收尾。