交付出件箱

发生产准备核查 · 2026-08-19

云机环境 · 非验收证据。所有结论下方均附物理命令输出。

一、发生产的唯一路径(已读脚本坐实)

sudo release-to-prod --mr <已合入test的MR编号> [--mr <编号>...] [--title "..."]

工具真实存在:/usr/local/bin/release-to-prod,dev2 在 sudo 白名单内(NOPASSWD)
脚本内部:清工作区 → fetch codeup → checkout -B main codeup/main → 拷 release 脚本 → 跑 release-main.sh
物理守门:case "$*" in *--mr*) —— 不点名 MR 直接 exit 1(严禁整条 test 推 main)
机制:从最新 main 建 release/* 隔离分支,只 cherry-pick 点名 MR 的提交,再 MR 到 main
🔴 合并 MR = 立即发生产,合并后无二次确认 —— 仔细检查的最后时点是合并前
🔴 非交互会静默取消且 exit 0 → 必须 printf 'y\n' | 喂确认
🔴 判定成功的唯一硬判据是流水线出现新 run,不是退出码、不是脚本输出

二、🔴 三个拦路问题(发之前必须解决,否则发了也白发/会出事)

阻塞① 结算根本不走 main 流水线 —— 现在合进 main 结算不会上线

流水线	部署什么	最近 run
main (5121207)	`deploy/docker-compose.prod.yml` → `doctor-api` / `doctor-web`(核心)	run#140 · 08-19 · FAIL
settle-prod (5174891)	`settlement/deploy/docker-compose.prod.yml` → `settlement-api` / `settlement-web`	run#7 · 08-10 · 至今没再跑过

settle-prod 仍指旧独立仓(台账原话),所以结算代码合进 main 只是进了总账、
生产结算容器一个字都不会更新。台账「切流门禁」写明:nginx 未切前合入 main
会致结算全站 404。
⇒ 需 root:切 settle-prod 流水线源 + 生产 nginx 切流 + reload。

阻塞② 核心 alembic 多头,生产迁移从 08-12 起就没成功过一次

生产 main 流水线连续 5 次全红(run#136/137/138/139/140),失败步骤日志尾部:

FAILED: Multiple head revisions are present for given argument 'head';
please specify a specific target revision, ... or 'heads' for all heads
ERROR [alembic.util.messaging] Multiple head revisions are present ...
run user script failed, exit code: 255

实测两棵迁移树的 head 数:

[main] migrations/versions:                    68 文件 · heads 2 -> ['phase70_001', 'store_poster_demo_flag']
[main] settlement/backend/migrations/versions: 14 文件 · heads 1 -> ['phase66_000_zero_guarantee']
[test] migrations/versions:                    69 文件 · heads 3 -> ['phase66_001', 'phase70_001', 'store_poster_demo_flag']
[test] settlement/backend/migrations/versions: 23 文件 · heads 1 -> ['phase71_000_support_qrcodes']

🔴 关键:test 的核心树是 3 个头,比 main 的 2 个还多 —— 发过去只会更糟,不会自愈。
✅ 好消息:结算树 main/test 都是单头、链条完整,结算迁移本身没病。
⚠️ 注意容器是 Started 之后才在迁移步挂的,所以"入口还活着"是真的;
但"迁移一直没应用"也是真的,不能拿入口 200 当迁移成功。

阻塞③ 这批带 9 个结算 migration,其中一个是 DROP

phase67_000_service_prices        phase68_002_signup_wx_identity   phase70_000_drop_pending_amount ←
phase67_001_change_clock_ts       phase68_003_store_closed_fields  phase71_000_support_qrcodes
phase68_000_payment_orders        phase69_000_review_link_guard
phase68_001_refund_offset

按台账 SOP:含 migration 必须单独标红报长官(数据难退)。
phase70_000_drop_pending_amount 还是"摘临时清理码"的前置条件。

三、当前差量(git fetch 后实测)

origin/main = ec0e6a49      origin/test = ecdff68c
test 领先 main: 674 commit   main 领先 test: 300 commit(隔离 cherry-pick 发版的常态分叉,不是错)

结算侧 main..test:  169 commit · 136 文件
核心侧 app/ 差异:   6 文件   (对照组,证明查法有效)

main 上 08-19 确有两次发布(release/mr-379、release/mr-460-461),都是核心侧
(4l-summary + 路径修复)⇒ 生产链路是活的,"生产没动"专指结算那批。

四、还缺的一件:MR 清单

release-to-prod 必须逐个点名 MR 编号,未列出的 MR 物理不会进发布分支。
待发范围据交接件是 #381 → #476(60+ 个),其中结算 25 件是 #464→#475、核心 1 件是 #476。
🔴 完整清单我在云机查不到(Codeup 令牌在 root 手里,release-pipeline-status 那把是纯只读 flow 令牌、
不含 MR 权限)⇒ 需长官或 root 给出要晋级的 MR 编号列表,我不猜。

五、建议的动作顺序

长官定 MR 编号清单(一次一令;别整批)
root 做三件前置:切 settle-prod 源 / 微信支付授权目录填 https://chat.tongban.love/ / 生产 nginx 切流
先修核心 alembic 多头(test 3 头必须先并成 1 头),否则生产迁移继续红
结算 9 个 migration 单独报备 + 真库排练(同版本库 + 存量行)
printf 'y\n' | sudo release-to-prod --mr N ... → 只建 MR 不自动合,链接给长官,等令合并
合并后:实查 run 号(不许顺延猜)+ 40 位 SHA 确认含本次 merge commit + health check 硬门禁
探针打在被改的那个路由
若 changed_files 含 settlement/deploy/nginx-settlement.conf → 部署后必须请 root
nginx -t && nginx -s reload(部署链只落盘不重载,不 reload = 改动物理无效)
台账记一条

六、我没验的(如实说)

Codeup 上 MR 的真实状态/清单(无令牌)
生产库现在的 alembic_version / alembic_version_settlement 实际版本(需 root 或核心方代查)
生产「待确认金额」存量单是否为 0(摘清理码的前置,需生产库只读权限)
chat.tongban.love 真打(生产入口,未经令不打)