上线发布怎么做检查表：版本、回滚、验证和沟通

上线发布不是点一下部署按钮。真正可靠的发布流程，要把版本范围、回滚方案、验证步骤和协作沟通都提前写清楚。

先确认发布范围

发布前先回答：

1. 本次改了哪些服务。
2. 是否包含数据库变更。
3. 是否包含配置变更。
4. 是否影响定时任务或消息消费。
5. 是否需要前后端同步发布。

范围不清楚，后面的验证和回滚都会变得模糊。

回滚方案要提前准备

每次发布都要能说清：

• 回滚到哪个版本。
• 配置是否能回滚。
• 数据库变更是否可逆。
• 新旧接口是否兼容。
• 失败后谁来执行回滚。

如果数据库变更不可逆，就要在发布前增加灰度、开关或补偿方案。

验证要覆盖关键路径

发布后不要只看服务启动成功。

至少检查：

• 健康检查。
• 首页或核心页面。
• 关键接口。
• 登录和权限。
• 新增功能。
• 老功能回归点。
• 日志和告警。

如果是后台任务，还要确认任务是否按预期执行，不能只看接口。

沟通比想象中重要

发布过程中要同步：

• 开始发布时间。
• 发布服务和版本。
• 验证结果。
• 异常处理。
• 发布完成结论。

这不是形式主义。出问题时，清楚的沟通记录能帮助团队快速判断责任边界和恢复路径。

维护建议

发布检查表可以固定成四段：

1. 发布前确认。
2. 发布中观察。
3. 发布后验证。
4. 回滚和复盘。

每次发布只要按同一张表走，就能减少遗漏和临时慌乱。