浏览 AI 知识库
部署前检查什么：构建、变量、数据库、域名和回滚
部署前检查不只是一遍构建。变量、数据库兼容、域名、健康检查和可用回滚点必须在上线前确认，否则旧版本也未必退得回去。
沿完整工作流推进
前一阶段的可检查结果，是下一阶段的输入；中间证据不足时停在当前阶段。
本地构建成功，上线仍可能因为一个变量直接停机
应用在本地构建成功，上线后因 `DATABASE_URL` 缺失启动失败；回滚版本又依赖刚执行的新迁移，无法直接恢复。
- 发布前已有可用回滚点
- 迁移与旧版本兼容性验证
- 公开入口和关键流程通过
先确认这次任务的起点、边界和交付
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | Node 服务、PostgreSQL、Nginx 和域名；发布包含代码与兼容迁移；目标窗口 20 分钟。 |
| 不能越过的边界 | 构建、变量、迁移、域名、健康与回滚逐项确认；秘密只核对存在和作用域；回滚点在部署前建立。 |
| 要交付的结果 | 部署前检查表与回滚点 |
从“冻结发布版本”走到“验证回滚”
| 当前阶段 | 实际处理 |
|---|---|
| 冻结发布版本 | 记录提交、构建命令、依赖锁和产物校验，确保发布内容与已测试版本一致。 |
| 核对环境与密钥 | 逐项比较环境变量名称、来源、scope 和缺失行为，生产值不进入日志或构建产物。 |
| 处理数据库与依赖 | 迁移、备份、兼容窗口、外部服务和域名证书有执行顺序与负责人。 |
| 定义健康与观察 | 写关键 URL、请求、队列、错误率、延迟和业务指标，明确观察时间和放行阈值。 |
| 验证回滚 | 记录上一稳定版本、配置和数据库恢复方式；不可逆迁移使用向前修复或兼容方案。 |
发布报告同时给出版本、配置、健康和回滚证据
| 层 | 本次输入 | 证据 | 放行条件 |
|---|---|---|---|
| 版本 | commit 8f31、锁文件和产物哈希 | 构建日志与校验值 | 与已测试版本一致 |
| 配置 | 变量名、scope、缺失行为 | 配置清单（值已脱敏） | 没有生产值进入产物 |
| 健康 | 关键 URL、队列、数据库和业务请求 | 预发布结果和阈值 | 所有关键检查通过 |
| 回滚 | 上一稳定版本、备份和恢复命令 | 恢复演练记录 | 责任人可在窗口内执行 |
版本和指标为示例；真实部署必须由目标环境负责人批准。
完成后的部署前检查表与回滚点
检查表记录构建产物哈希、必需变量名称、迁移兼容性、备份、健康端点和旧镜像。演练发现旧镜像可读新字段后才批准发布；发布后观察 15 分钟，错误率和健康检查稳定。
为什么“服务健康，真实用户仍无法访问”还不能交付
服务健康，真实用户仍无法访问
- 原因
- 健康端点没有覆盖代理、域名或依赖
- 怎么改
- 同时验证公开 URL、关键流程和后端依赖，不只看进程存活