yml2213
0b48313617
feat(deploy): 部署改成按需重建，无 schema 变更自动跳过备份
每次部署都无条件重建 backend + web 两个镜像（实测后端 3m35s、前端 2m54s），
并且每次都在迁移前 pg_dump + 传 OSS（生产 492MB dump 那一步约 12 分钟）；
只改了后端也要把前端整条链重跑一遍。
改动：
- 新增 deploy/lib/classify-changes.sh：把改动文件映射成"要重建哪一端"，
规则保守——apps/backend/** → backend、apps/frontend/**|deploy/caddy/**|前端 Dockerfile → web、
文档/部署脚本/测试文件 → 不重建，compose 文件与未知路径 → 两端都重建。
- ubuntu-deploy.sh 用 .deploy-state（上次成功部署的 commit + .env 指纹）算 git diff，
未变化的一端不 build、也不 --force-recreate，容器保持运行；若它没在跑则用现有镜像拉起。
两端都要建时合并为一次 compose build（bake 并行）。
- 备份：改动不含 apps/backend/src/db/migrations/** 时自动跳过（--backup 强制、
--skip-backup 无条件跳过）；算不出改动范围（首次使用、force push）时不自动跳过。
- compose pull 改 --policy missing：不再每次重新校验 postgres tag，避免顺手静默升级数据库镜像。
- 新增 --dry-run（打印计划后退出，含基础镜像 digest）、--all、--backend-only/--web-only；
部署结束打印各阶段耗时，回答"这次怎么比上次慢"不用靠推算。
- .deploy-state 进 .gitignore；README 与 docs/部署启动与数据库重建.md 同步。
验证：新增 7 个用例直接执行分类脚本断言"改动→重建范围"，并守住"状态只在健康检查后才落盘"
等关键顺序；全量 595 个单测、typecheck、lint、check:sql 全通过。
2026-10-03 16:29:05 +08:00
..
2026-10-03 16:29:05 +08:00
2026-09-19 11:06:32 +08:00
2026-10-03 14:27:38 +08:00