构建与部署脚本化

一句话

第 6 章处理的是流水线里的「体力活」：怎么把构建与部署写成脚本。它的核心命题只有一句——构建脚本和部署脚本是生产代码，不是一次性命令的堆积：要进版本库、要分层、要被重构、要能测试。由此推出三条硬规矩：所有环境共用同一套部署脚本（差异只在外部配置）、部署过程必须幂等、按变更频率把部署分层。

Glossary · 术语表

坐标

本章属 Part II「部署流水线」，紧接 Ch5 之后：Ch5 画出关卡的形状，本章回答每个关卡里那个格子具体由什么执行。它向下承 Ch2「配置管理」（「同一套脚本 + 外部配置」的后半句靠 Ch2 落地），向上启 Ch7「提交阶段」与 Ch11「管理基础设施」。对应现实里的问题是：一个团队的 build.xml / Makefile / deploy.sh 演化三年之后，为什么没人敢碰。

这章要解决什么

流水线的图谁都画得出来，真正拖垮团队的是执行这张图的那堆脚本。它们的典型下场：一份三千行、只有作者看得懂的 build.xml；deploy-dev.sh / deploy-uat.sh / deploy-prod.sh 三份各自打补丁、早已互不相认；一句写在 wiki 上的「运行前请先手工停掉 A 服务」。

不解决会怎样？慢性的代价：脚本没人敢改，新需求只能往里塞 if，构建时间从 3 分钟涨到 25 分钟，越过 Ch7 给提交阶段定的十分钟预算——开发不再等结果，持续集成名存实亡。急性的代价：就是科普版里骑士资本那 45 分钟；美国证监会 2013 年的执法文件指其部署流程缺乏自动化与一致性校验。「8 台里有 1 台不一样」，正是脚本化 + 幂等要消灭的东西。

核心内容，讲透

① 构建工具的本质是一张依赖图——分歧在「节点是什么」

所有构建工具做的是同一件事：把构建拆成若干带依赖关系的目标，拓扑排序后依次执行。分歧在于节点是什么。

产物导向（product-oriented），代表是 Make：节点是要产出的文件。app 依赖 a.o、a.o 依赖 a.c，Make 比对文件时间戳，源比产物新才重做。好处是增量构建天然成立；代价是判据脆弱——时间戳在很多文件系统上只精确到秒，同一秒内的改动会被整个漏掉，而从版本库重新检出会把所有文件的时间戳刷成「现在」。于是团队最终养成「出问题就 clean build」的习惯，增量的好处全还了回去。

任务导向（task-oriented），代表是 Ant / NAnt：节点是一件要做的事。好处是想干什么写什么，不受「必须映射到某个文件」的约束；代价是工具不知道能不能跳过，跳过逻辑得你在 target 里自己写，默认行为往往是全跑。

书里还点出第三条路：约定优于配置（convention over configuration），代表是 Maven——它规定死目录结构与生命周期（src/main/java，compile → test → package → install），你不写脚本、只填配置。作者给它的评价是诚实的两面：新项目开箱即用、团队之间格式统一；一旦需要偏离约定，成本陡增，最后往往得写插件，而插件比原来那段脚本还难懂。

以及第四条：干脆用一门真正的编程语言——Rake（Ruby）、Psake（PowerShell），后来是 Gradle。构建逻辑复杂到需要条件、循环与抽象时，用 XML 表达是自虐。代价是没有约束的语言会让构建脚本长成第二个应用程序——所以这条路必须配上下一节的纪律。

② 构建脚本是生产代码，就按生产代码的规矩管

这是本章的灵魂，也最常被跳过。构建与部署脚本要进版本库，和它服务的代码同仓同分支，走同样的评审。理由很直接：代码的某个版本，只能用同一版本的脚本正确地构建和部署。脚本放在别处（某台 CI 机器的「构建配置」界面、某人的 home 目录），你就永久失去了「回到三个月前那版并原样重现」的能力。

同规矩还派生出几条纪律：分层去重，公共逻辑抽成可复用模块，别复制粘贴；一律用相对路径，写死 /opt/app 的脚本只能在作者那台机器上跑；构建产物输出到源码树之外，否则 clean 只能靠 .gitignore 和运气；制品与修订号绑死，文件名或元数据里带上提交号，生产出事才能一路查回那一行代码。

还有一条容易反着做：「测试失败」必须让构建失败，但别一失败就立刻中止。把「有失败」记成标记，让这一轮跑完再在末尾整体失败——这样一次构建能看到全部失败，而不是修一个、发现下一个、再等十分钟。

③ 同一套脚本，部署到每一个环境

这是全章最具操作性的一条：开发机、CI、预生产、生产，跑的是同一份部署脚本，环境之间的差异只以外部配置的形式存在（承 Ch2：配置也进版本库，只是和代码分开管）。

为什么这么硬？因为部署脚本本身就是被测对象。你在预生产把部署演练了二十遍，如果生产用的是另一份脚本，那二十遍一次也没测到真正要跑的那段代码。「只在发布日才第一次执行的代码」就是风险本身，而每个环境一份脚本，正是在系统性地制造这种代码。

代价要认：脚本得参数化，参数一多就长出自己的复杂度，得有一套配置管理方案（配置仓库、模板渲染、密钥托管）托住它。原则是让环境之间只差配置，不差行为——一旦某个环境需要「多做一步」，先问这一步能不能在所有环境都做。

④ 幂等：脚本描述的是状态，不是步骤

幂等的定义是：不管目标机器现在处于什么状态，脚本跑完之后它都处在正确的状态；再跑一遍，什么也不变。

它和「把手工步骤录成 shell」的差别是根本性的。命令式脚本写的是「解压、建目录、改配置、启动服务」，一旦第三步崩了，机器停在中间状态——重跑会因目录已存在而失败，只能上机手工收拾。收敛式脚本写的是「这个目录应当存在、这个配置应当是这样、这个服务应当在运行」，每次先读当前状态、只改不一致的那部分。于是「重跑一次」成为一个永远安全的动作——这条性质正是自动化敢于无人值守的前提。

这也是 2010 年前后 Puppet / Chef（以及稍后 Ansible）那一代工具的共同设计。本章还配了一条同源纪律：按变更频率分层部署——操作系统与中间件、应用二进制、配置、数据与 schema 各一个脚本、各自的节奏。混在一起的后果是，改一行配置也要把中间件重装一遍。

⑤ 能用系统原生包就别自己造，最后一步永远是冒烟测试

书里有一条偏工程口味但很管用的建议：能用 RPM / deb / MSI 就别自己发明打包格式。它们自带依赖声明、安装 / 卸载 / 升级的标准动作，以及「这台机器上装了哪些版本」的可查询数据库——自己写脚本都得重造一遍，且大概率造得更差。代价是跨平台要维护多套包，包管理器的抽象在需要精细控制时也会碍事。

最后是集成冒烟测试：部署脚本的最后一步应当是一小段「它真的活了吗」的检查——进程在不在、端口通不通、数据库连得上。只花几秒，却把常被混为一谈的两件事分开：「脚本返回 0」不等于「服务能用」。

关键权衡与选型

表 1 · 四类构建工具：各自买到什么、代价是什么

表 2 · 部署脚本：一套共用 vs 每环境一份

表 3 · 三种部署范式：命令式 / 幂等收敛 / 不可变替换

为什么重要 / 落到真实系统

这一章的三条规矩今天已沉淀成行业默认，只是换了名字：「构建脚本进版本库」变成 CI 配置即代码（Jenkinsfile、工作流 YAML 就躺在应用仓库里）；「同一套脚本部署到每个环境」变成同一个容器镜像 + 每环境一份参数；「幂等」变成声明式基础设施的立身之本——Terraform 的 plan / apply、Kubernetes 的调谐循环，都是图 3 右边那个回路。

面试里常被追问的那句「为什么同一个制品要一路走到底」，答案的后半截——脚本也要一路走到底——就在本章。

易错点与争议

• 把「脚本化」误解成「把手工步骤录下来」。 录下来的 shell 只是把人的错误固化成机器的错误：不可重跑、不可读、不可测。本章要的是分层、幂等、进版本库这三条，而不是「有个脚本」。
• 拿构建工具去做部署。 书里明确劝阻：Ant / Maven 是为构建设计的，拿它 ssh 到二十台机器上改配置会很别扭，还会把一堆构建期依赖带上生产机。部署该用部署工具。
• 幂等不是万能的，数据是例外。 「重跑一次」在数据库迁移上不成立——加一列、改一个值天生不可重复执行，得靠版本化迁移脚本 + 迁移记录表（本书 Ch12 专讲）。把幂等当成放之四海的口号，最容易在数据这一层翻车。
• 「不要把构建产物签入版本库」要加个脚注。 书里反对的是把 jar 和源码混在一个仓里，不是反对保存制品——制品应当进制品库（Nexus / Artifactory / 容器镜像仓库），可寻址、可追溯、可清理。
• 时代局限。 本章写于 2010 年，工具清单停在 Ant / Maven / Rake / Psake，配置管理刚出现 Puppet / Chef；今天 Gradle / Bazel 接手了构建，容器与编排接手了部署。更有意思的是幂等这一条被部分绕过了：不可变基础设施不「把机器改成正确状态」，而是「不改机器，整台换掉」——比幂等更强，连「收敛逻辑自身写错了」这个风险都一并消掉。但它没有推翻本章，只是换了条更彻底的实现路径：同一套脚本、同一个制品、一路到生产，这三点原封不动。
• 争议：约定优于配置到底值不值。 公允的说法是：它把「简单项目的构建」从一个问题变成了非问题，同时把「复杂项目的构建」从困难变成了痛苦。选它之前该问的不是「它好不好」，而是「我这个项目多半会不会需要偏离约定」。

要点