部署、发布、回滚与观察：把功能交到用户手里

代码已经合并，收藏按钮却没出现在网站上。或者网站更新了，点击时提示找不到数据表。交付涉及代码、配置、数据和流量，不能只用“构建成功”判断完成。本章按一次小发布看这些环节怎样配合。

构建发布与运行 2026/10/254 分钟阅读

部署、发布、回滚与观察：把功能交到用户手里

1. 部署和发布可以分开

部署是把某个版本放进运行环境；发布常指让目标用户开始使用能力。新代码可以先部署、暂不开启入口，再逐步开放。两者经常一起发生，但不是必须同时发生。

持续交付强调让软件随时处于可发布状态，正式上线仍可由人决定；持续部署则把通过规定检查的变更自动送到生产。两者都常写作 CD，阅读资料时要先确认作者指的是哪一个。

收藏功能可能需要新版界面、新接口、收藏表、访问规则以及配置。按依赖关系安排步骤，例如先准备兼容新旧代码的数据库结构，再部署新代码，验证以后打开入口。

Text
发布前：记录旧版本，确认备份可恢复，检查配置和关键测试
发布时：应用兼容的数据变更，部署已验证产物
发布后：登录、保存、刷新、取消，检查错误与权限
失败时：关闭入口或切回兼容旧版，继续核对数据状态

这是教学清单，具体步骤要根据系统调整。例如本知识库的文章存于数据库，只部署 Git 中的 Markdown 不会自动更新线上正文；内容同步也属于发布的一部分。

把旧字段直接删除后，旧版程序可能再也无法工作。这时切回旧代码并不能恢复被删数据。可以采用先扩展、再迁移、最后收缩的方式：先增加兼容结构，让新旧程序过渡；确认迁移和旧版退出后，再移除旧结构。

即使保留了备份，也要考虑恢复耗时与备份之后的新数据。回滚应用、撤销数据库变更、恢复备份是不同操作，不能用一个“回滚按钮”含糊概括。

先让少量用户使用，再逐步增加，常称为灰度或金丝雀发布。它能限制某些问题的影响范围，但需要可信的流量分组、指标和停止条件，否则只是“发布慢一点”。

也可以准备两个运行版本，再切换流量。这类蓝绿方式更容易切换代码版本，但如果两边共享同一数据库，仍需数据兼容。部署策略解决的是一部分风险，不能代替设计和测试。

不要只看服务器是否还活着。收藏成功率、错误类别、请求耗时，以及用户能否重新读到保存结果，都更贴近实际体验。日志记录具体事件，指标提供一段时间的数量或分布，追踪帮助串起一次跨部件请求。

服务指标可称为 SLI，为它设定目标称为 SLO。例如“过去七天有效收藏请求的成功比例达到约定值”。必须先定义哪些请求计入分母、什么算成功，才有可比较的数字。本课程不规定所有系统采用同一个百分比。

一次请求耗时达到目标，不代表整段时间达到目标；平均值正常也可能掩盖少数特别慢的请求。观察窗口应覆盖实际使用，而不是上线一分钟没报错就永久结束检查。

新版出错时，是否总应该立即切回旧版？先判断旧版是否兼容当前数据与配置。若不兼容，关闭新入口、限制影响或前向修复可能更合适。发布前准备并演练恢复路线，比事故中第一次猜测可靠得多。

知识库的代码和文章可能来自不同存储。一次完整发布应回答：网页运行哪次提交，数据库正文对应哪份内容，旧内容是否有可恢复的记录？只看到构建绿色，无法回答后两个问题。

可以给待发布文章保存修改前后的摘要值，并在写入前检查线上版本有没有被别人编辑。发布后重新读取正文比较，再从正式域名打开文章。这是本项目的发布设计：用有限的变更清单、备份和冲突检查，让代码与内容一起交付。数据库结构变化还需另行评估，不能因为文章更新成功就顺便删除旧字段。

2026-10-25 查阅。下面的链接支持本节的机制说明；练习场景和选型建议是本教程的教学设计。