john
26 lines
4.9 KiB
Markdown
26 lines
4.9 KiB
Markdown
# 生产发布规则
|
||
|
||
> 每次生产发包前先读：[docs/发包必看.md](docs/发包必看.md)。那里记录了 2026-06-27 Portal/goosed 事故后的强制检查项。
|
||
>
|
||
> 生产发布的完整自动化验收、场景目录、豁免规则和机器报告规范见：[docs/production-release-guardian.md](docs/production-release-guardian.md)。该文档是 `103` 发布的强制守门员；所有适用场景通过且取得明确人工批准前，不允许上传或发布。
|
||
|
||
1. `103` 是正式生产主机，`105` 是云侧入口/历史链路；**本机一律不允许直接 `rsync` 到 `103` 或 `105`**，也不允许在线改源码后继续运行。
|
||
2. **禁止 SSH 登录 `105` 直接修改业务代码**（含服务号菜单脚本 `scripts/wechat-mp-menu.mjs`）。105 上文件是部署产物；变更必须：本地 `test-memind` 修改 → Git commit → 正式发布 → 必要时在目标环境执行 API 同步。详见 [docs/105-server-operations.md](docs/105-server-operations.md)。
|
||
2. **Portal 生产必须是无源码 runtime 模式**：构建只发生在本机 Mac，产物是 `.runtime/portal/`；`103` 只接收 runtime artifact、继承持久目录、启动服务，**禁止**在 `103` 上 `npm install`、`npm run build` 或保留可运行源码树。
|
||
2. `MindSpace` 独立服务同样必须走单独 runtime artifact：本地 `node scripts/build-mindspace-service-runtime.mjs` -> `bash scripts/release-mindspace-service-prod.sh` -> 上传 `103` -> 备份 `/Users/john/MindSpace` 与共享 `Memind/.env` -> 原子切换到 `/Users/john/MindSpace` -> 健康检查 `127.0.0.1:8082/health` 与 `/mindspace/v1/contract`；禁止手工 SSH 改线上 `/Users/john/MindSpace` 源码。103 当前拓扑见 [docs/103-runtime-topology.md](docs/103-runtime-topology.md)。
|
||
3. Portal 生产发布必须先构建候选 runtime，并只通过 `scripts/release-portal-canary-prod.sh` 启用用户级灰度。灰度只能命中明确的不可变用户身份，未命中、身份解析失败或候选不健康必须继续走稳定版本。`scripts/release-portal-runtime-prod.sh` 仍是整包替换脚本，在同一候选的灰度验收和晋升证据校验完成前禁止非 dry-run。
|
||
4. `scripts/release-prod.sh`（源码包发布）已停用，不得再用于 Portal；`rsync_to_server.sh` 与任何面向 `105` 的直接同步脚本也只保留为禁用提示。
|
||
5. Portal 发布包不得携带运行态资产；`.env`、`data/`、`users/`、`.tailscale/`、`public/plaza-covers/`、`logs/` 只能从线上现有 live 目录继承。`/Users/john/MindSpace` 是独立 MindSpace Service 的生产根目录，不属于 Portal runtime 包；`/Users/john/Project/Memind/MindSpace` 只允许作为旧链路兼容/存量目录处理，不得再被写成 MindSpace Service 的当前根目录。
|
||
6. runtime artifact 必须包含 `server.mjs` 与 `mindspace-sandbox-mcp.mjs`（`sandbox-fs` 扩展依赖的独立子进程入口）。
|
||
7. 生产发布必须从已验证的完整 `main` 打整包：分支代码必须先合并进 `main`，禁止从功能分支、单个 commit、单个修复或局部差异单包发布。
|
||
8. 每次生产发布前必须确认 CI 已通过，且没有未合并的关键变更。
|
||
9. 每次生产发布前必须先通过 `bash scripts/check-release-ready.sh`，确认分支不落后 `origin/main`、工作区干净、发布来源可追溯。
|
||
10. 每次生产发布前必须先做全量备份；发布失败必须自动回滚到切换前的 live 目录。
|
||
11. 发布清单必须记录：本地 commit、分支、发布时间、发布编号、是否含额外手工环境变更。
|
||
12. Portal 生产验证至少包含 `http://127.0.0.1:8081/api/status` 的 200 健康检查，并补充本次功能对应的业务路径验收；Plaza 仍按各自发布流程单独验收。
|
||
13. 生产热修复也不能绕过这套流程；“为了快”不是跳过备份、跳过 commit、跳过发布包的理由。
|
||
14. 每次生产发布必须生成与完整 `main` commit 和 runtime artifact SHA256 绑定的 Gate report。常规发布执行 16 项核心场景加 Git diff 自动选择的影响域场景；所有被选择场景必须真实执行并满足 `failed=0`、`skipped=0`、`blocked=0`、`unknown=0`、`cleanup_failed=0`。
|
||
15. 187 项是完整回归目录，不是每次发布的固定执行数量。鉴权、数据库、runtime 构建、依赖、共享入口、发布闸门自身或任何未映射的运行时代码发生变化时，影响选择器必须自动升级为全量 Gate。
|
||
16. 风险分层报告必须记录线上基线 commit、changed paths、核心场景、影响域、最终选择结果和选择策略；发布校验器必须从 Git diff 重新计算并核对，禁止人工删减选择结果。正常风险分层 Gate 不使用逐项 `not_applicable`，被选择的场景必须通过。
|
||
17. 完整 187 项 Gate 用于高风险发布、选择器或发布规则变化、无有效基线、灰度/生产失败后的重新验证，以及定期回归。即使 Gate 全绿，也不能把整包替换脚本当作灰度发布入口。
|