每次部署前我都会检查什么

我有一次在周五下午搞挂了生产环境。推了一个配置变更，在预发布环境看起来没问题，但有个环境变量引用了开发数据库的URL。

整个站挂了40分钟。在周五。下午4点。手机响个不停。

从那以后，我有了一份清单。不长。但我每次都会照着做。没有例外。哪怕是"就改了一行CSS"也不例外。

这份清单

1. Diff一下变更

部署前，我会看一下到底有什么东西要上线。不是我以为改了什么——是实际改了什么。

git diff main...HEAD

我会拿diff和我预期的变更做对比。如果diff里有我没预料到的东西，就停下来搞清楚为什么。

这招帮我抓到过意外留下的debug日志、遗留的测试数据、以及我没意识到已被暂存的环境配置变更。

2. 验证配置文件

JSON配置文件很脆弱。少一个逗号全崩，而且报错信息通常只写"Unexpected token"这种没啥帮助的东西。

我会把每个修改过的配置文件粘到JSON验证器里再部署。周五下午4点你的眼睛会漏掉语法错误，但工具不会。

3. 检查环境变量

就是这个坑了我。预发布和生产看起来一模一样，但环境变量不同。数据库URL、API密钥、功能开关——任何一个搞错了都可能导致难以追踪的隐性故障。

我有一份不同环境之间有差异的环境变量清单，每次都会逐一核对。麻烦吗？是的。比搞挂生产好吗？也是的。

4. 测试核心路径

我不会在每次部署前跑完整测试套件（那是CI的事）。但我会手动测试核心用户路径：

• 用户能注册吗？
• 能登录吗？
• 能完成产品的主要功能吗？
• 能付款吗？

如果这些里有任何一个挂了，其他的都不重要。

5. 检查资源大小

发布前端变更之前，我会检查有没有新资源大得离谱。一张没压缩的图片或者一个没压缩的JavaScript bundle能让你的加载时间一夜之间飙升。

快速检查：

• 没有超过200KB的图片（除非有充分理由）
• CSS和JS已经压缩
• 没有意外添加的新字体

6. 确认回滚方案

如果出了问题，我能快速撤销这次部署吗？

大多数项目来说就是git revert然后重新部署。但如果部署包含数据库迁移，回滚就复杂多了。在部署之前搞清楚这个，别等到事故中才想。

清单上没有的东西

注意哪些不在清单上：

• 跑所有测试——CI负责。CI上测试过了我就信。
• 代码审查——合并之前已经做了。不是部署时要做的事。
• 更新文档——重要，但不是部署的阻塞项。

部署清单专门针对"这会不会搞挂生产？"不是关于代码质量、文档或流程的。那些也重要，但它们发生在更早的阶段。

周五规则

我不再在周五下午部署了。如果出了问题，我希望有一整个工作日来修，而不是一整个周末的焦虑。

周一到周四，工作时间。这是我的部署窗口。例外存在，但很少而且是有意为之。

---

清单不是什么激动人心的东西。没人写一篇关于部署清单的博客就出名了。但清单的意义不是有趣——是抓住你忘记的那一个东西。而它只需要救你一次，就值回你每次花的那两分钟。