3.3 KiB
3.3 KiB
PROGRESS · 发布通路修复单 2(2026-10-14)
- 分支:
codex/release-path-production-20261014 - issue:#74。先并入当时的
origin/staging(合并提交d13250f4),没有改写已推历史。 - 产品选 A:恢复点带上属主和权限,并在本机真实 PostgreSQL 17 上演练。没有点生产按钮。
- 新记录:BUG-1350。不是 BUG-203 的复发。BUG-203 是恢复点锁文件的所有权。
做了什么
- 恢复点导出只保留自定义格式。还原后比较表权限、列权限、表属主,不一致就不写恢复点记录。记录里写
RECOVERY_FORMAT=2。创建恢复点的按钮输出仍是原来的 7 行,那个工作流文件没有改。 - 部署和迁移在允许回退时,读主机上的恢复点记录。版本低于 2 就拒绝,并提示先做新的恢复点。正向部署不要求这份文件。
- 演练不再改类型属主。迁移前后比较授权,收回了原有授权就退出 1。人物表列级读取权缺了就退出 4。新的一次性库补上迁移角色的连接和建对象权限,因为整库导出带不走数据库本身的权限。
- 手册的整库还原去掉丢掉属主和授权的参数。还原后补回迁移角色在这个库上的连接和建对象权限。读网站账号之前先设登录身份,否则行级安全会把行藏起来。
和任务书不完全一样的地方
- 空库必须留着
public。备份是去改它的属主,不是重新创建它。先删掉会停在「schema public 不存在」。 - 数归档会话时,列还不存在不能写在同一条查询里,数据库会在解析阶段就拒绝。先看列在不在,再计数。没有这一列时仍输出
absent。 - 本机演练用的是 fixture 里的 PostgreSQL 17,不是生产主机上的那一份备份。生产恢复脚本要求生产目录,不能在这台电脑上原样执行。导出参数、加密方式和还原核对是按脚本重放的。
自测
| 命令 | 结果 |
|---|---|
bash -n 四个生产脚本 |
退出码 0 |
tests/test_rehearse_production_migrations.py |
6 通过,退出码 0 |
tests/test_resolve_release_revision.py 与上一份一起 |
13 通过,退出码 0(授权那条断言是在这之后加上的,演练测试又单独跑过) |
tsc --noEmit -p frontend |
退出码 0 |
npm run lint --prefix frontend |
退出码 0,0 error,123 条原有 warning |
frontend/tests/staging-backend-workflows.test.ts |
44 条里 39 通过、5 失败、0 取消。失败是这台 Windows 机器的环境:python 退出码 9009、两条缺 rsync、临时目录改权限被拒绝、纯文档范围脚本退出码 49。生产部署、恢复点、生产迁移合同(第 32、34、35、36、37 条)通过 |
| 本机 PostgreSQL 17 演练 | 见 docs/testing/production-migration-rehearsal-20261014.md。权限三样一致,rehearsal_ok=1,退出码 0,演练库 0 个残留,网站角色读到 1 行 |
预检
scripts/pre_work_check.py --remote-timeout 8 --command-timeout 45 退出码 1。远端仓库可见,适配器正常。碎片扫描 90 秒超时,聚焦测试 45 秒超时。这是这台电脑上预检超时的老问题,没有改台账,也不写成预检通过。
没做
- 没有点生产按钮,没有连生产主机。
- 没有推
staging或main。 - 没有改测试环境工作流、门禁路径清单、纯文档判断脚本。