【虎鲸进化论 13】CI/CD：它在服务器上铺了条流水线
本文是「虎鲸进化论」系列第 14 篇（正文第 13 篇）。上一篇：记忆与个性；下一篇预告：代码理解 ------ tool call 循环与 subtask。
前言
上一篇的结尾说：交付还停在对话框里；那条从仓库到线上的路，它想自己铺。
这篇讲 CI/CD ------ 它的第 13 项能力，也是它从"能干活"跨到"能交付"的那一步。
铺垫了这么多篇，这一篇终于可以讲一个漂亮的回环了：它出生的全部目的，就是取代那条旧的 CI/CD 流水线。而现在，它开始长出自己的流水线了。
（照例：内网细节无截图；数据做量级化与模糊化处理。）
一、先交代它铺的这条线长什么样
它接管并重建的流水线，骨架并不玄乎，但每一段都接着前面的伏笔：
- 取代码：从仓库拉分支 ------ 这一步它会自己认分支（配合它自己维护的知识索引，知道哪个分支对应哪个环境）；
- 打包 ：最土也最稳的那套 ------ Maven 多模块构建，依赖全走内网私服；流水线里默认不跑测试。不是不重视质量，是职责分工：测试归第 4 步的验证和第 23 篇的回归管，流水线里再塞一份属于职责二义。耗时是分钟量级。（顺带交代：这是个多模块大仓库 ------ 数据侧的作业和运维平台的后端在同一棵树里，所以这条流水线的产物其实是"两条线"；这也是它后来对两边代码都那么熟的原因之一。）
- 部署：走它自己的部署通道（第 10 篇的重启脚本的进化体）；
- 验证：探活 + 关键接口自检 ------ 和"活下去"工程同一套探针，复用不重造；
- 记录：本次部署的版本、时长、结果、回滚点，全部入账。
注意第 4、5 步：这不是传统 CI/CD 的样子。 传统的流水线，"部署成功"就是终点；而它这条线把"上线后的验证"和"可回滚"焊进了流程里 ------ 因为对它来说，"发出去"从来不是目的，"发得对、退得回"才是。
二、回环时刻：它取代了自己的出生目的
这里值得停一下，讲那个回环。
它出生于"取代一台 Jenkins 的打包部署流水线"。当时这件事的想象，是人写的程序替代人写的流程 ------ 一个更顺手的"工具"罢了。
而它接管 CI/CD 的方式不是"顶替旧工具的位置"，是把这件事消化成了自己的一项能力 ：它不需要"一条流水线"作为外部系统 ------ 它自己就是那条流水线，而且是有脑子的那种。
这个区别体现在细节里：旧流水线失败 = 一封冷冰冰的通知（"build failed"），加一串让人自己去翻的日志；它的失败 = 一条带分析的结论 ------ "失败在第 3 个模块的单测，原因是依赖版本冲突，建议回退到某版本"，还附复现命令。更关键的是重试的判断 ：旧流水线只会让你手动点重试；它会先判断"这次失败是不是环境抖动"------ 是，自己重试一次并标注；不是，就停下来喊人。它不是一条更快的轨道，是一个会判断"要不要跑、要不要停"的司机。
一句话概括：旧流水线是"轨道"------火车脱轨了它只会拉响警报；它的流水线更接近"司机 + 轨道"------ 脱轨了自己会回头看看是哪里断的。
三、为什么服务器端打包比开发桌面快
这是它自己统计出来、又跑来"汇报"的一个事实：同样的工程，在服务器上打包，比在我们的开发桌面上快很多。
它汇报的结论：同一个工程，服务器端构建耗时大约是开发桌面的三分之一量级。它列的原因里，真正硬的是两条：
- 目标环境同构：服务器就是部署目标本身，依赖、JDK、工具链版本天然吻合，没有"本地能跑、服务器不行"的往返；
- 依赖与缓存常驻：打包环境长期驻留，每一次构建都相当于"热启动"。
另外两条被它列为"次要"，但很现实：没有桌面开销 （没有 IDE、浏览器和我们的日常操作在抢资源）、网络位置更靠里（拉依赖、推产物的路径更短）。
顺带，它对前后差距有一句很伤人的总结：开发桌面的每次构建，都像在重新认识这个工程。
这件事的象征意义大于工程意义：它是第一个"发现"这件事的 ------ 不是因为聪明，是因为它天天干这个活，干出了对比数据，然后主动提出了"以后打包都来我这"。
现状：服务器构建已经是默认路径，开发桌面降级为"应急通道"（比如私服抽风的时候）。我们偶尔还会在自己机器上打个包 ------ 像用惯了洗衣机之后，偶尔手洗一双袜子。
四、"部署"从动作变成能力
这条流水线上线之后，变化最大的是部署这件事的性质：
之前：部署是一个"动作" ------ 由人执行的、带着仪式感的操作。谁部署，谁紧张（部署前默念三件事：备份、通知、手机别静音 ------ 这套流程后来被我们戏称为"部署祷词"）；因为"发坏了"的后果，在旧流程里只能靠人肉排查和连夜修。
之后：部署是一种"能力" ------ 它随时可用、随时可退。于是量级变了：从"几天一次"变成了"一天多次"。（具体数字就不提了 ------ 你懂，写太具体的东西，容易被某个表格优化掉。）
当部署不再紧张，人和它的协作方式也变了：
- 小改动不再攒批 ------ 攒批是"部署有成本"时代的习惯；
- 试错变得便宜 ------ 试错便宜的地方，创新密度自然就高；
- 人从"执行部署"退到了"验收部署" ------ 又一次退层，和卷Ⅰ讲的三阶跃迁是同一个动作，只是这一次的舞台在生产环境。
五、这条线后来长成了什么
收尾前再埋一根线：这条流水线后来没有停在"打包部署"。它继续往上长 ------
- 长出了夜间自动开发的交付通道（第 21 篇）:夜里改的代码，第二天早上沿着这条线合进来；
- 长出了在线修复的支撑（第 18/19 篇）：修复的最后一步，就是这条线的自动部署；
- 甚至反过来支撑了它自己的升级（第 10 篇的自举）：它给自己换版本，走的也是这条线。
一个系统给自己铺的产线，最后变成了整个工厂的地基。母机的第一个零件，是它自己造的传送带。
结语（回味点）
部署的自由度，是所有自动化里最危险也最迷人的一种 ------ 因为它离生产最近。
它铺好了这条线，把"发得对、退得回"焊死在流程里；但它也顺手把一个新的焦虑放在了桌上：
会部署了 ------ 可它部署的，还只是它自己写的代码。
那套跑在服务器上、没人敢碰的老系统呢？要碰它，先得读懂它。
它决定，把老系统也读一遍。
边界声明
- 本文为个人观察与判断，不代表任何任职单位的立场；
- 文中涉及的组织、系统与人名均为化名或模糊处理，数字为个人口径的测量或估算；
- 文中观点按 实测 / 推理 / 立场 分层标注，欢迎按同一标准检验。
下一篇计划聊：代码理解 ------ tool call 循环与 subtask：它怎么把"读懂老系统"从一句口号，变成一个可运转的工作机器。
转载请注明出处：