Files
ClassHelper/docs/management/upgrade.md
T
LoveChengke 19c2aa07b2 feat(docs,scripts,build): 用 docfx 搭文档站并发布到 GitHub Pages,版本号收口成脚本迭代
文档站(`docs/` 就是 docfx 项目,发布在 https://lovechengke.github.io/ClassHelper/):

- 四章 + 常见问题 + 完整参考,共 44 页:快速上手(8 页)/ 应用帮助(10 页)/
  管理运维(6 页)/ 开发文档(11 页)。信息架构照 ClassIsland 文档站来:
  顶栏分章、左侧章节导航、右侧本页目录、上一页 / 下一页、站内搜索、深色主题跟随系统;
- 自定义模板覆盖(`templates/classhelper/`):把 docfx modern 模板那套英文 UI 文案
  (In this article / Improve this doc / Next…)换成中文,补 GitHub 入口与版本徽标,
  并加一层只调排版与配色的 `public/main.css`(不动 DOM 结构);
- 站点顶栏的版本徽标取自根 `package.json`(`docs/build.mjs` 用 `--metadata` 注入),
  不在文档里写第二份 —— 否则一定漂;
- 404 页单独生成:GitHub Pages 的项目页挂在 `/<仓库名>/` 子路径下,而浏览器是按**被请求的路径**
  解析页面里的相对链接的,所以 `<base>` 必须钉到站点根,由 `build.mjs`(本地 `./`)与
  workflow(CI 传 `/<仓库名>/`)分别注入;
- 构建前清空 `_site`:docfx 只覆盖不清理,删掉或改名的页面会以旧文件留在目录里,
  而 Pages 上传的是整个目录。

版本迭代(**每一次 releases,不是每一次提交**):

- 新增 `scripts/version.mjs`。这个仓库里同一个版本号散在 **10 个文件**里(5 份 `package.json`、
  `deploy/package.runtime.json`、两个 compose 的镜像 tag、插件 `manifest.yml`、以及插件 C# 里的
  `PluginVersion` 常量),手工改必然漏一处,而漏掉的那处**不会报错**,只在某个不常走的分支上
  表现为"版本号对不上"。现在收口成两条命令:`pnpm version:check`(逐处比对,不一致 exit 1)
  与 `pnpm version:bump patch|minor|major`(一次改写全部 10 处,任何一处匹配不到或匹配到多处
  就直接失败退出,不做尽力而为的部分改写);
- `AGENTS.md` 新增 §4.4「版本迭代(每一次 releases,不是每一次提交)」:写清版本号落在哪 10 处、
  完整发布命令序列(体检 → 验收 → `dist:all` → 哈希清单 → 推 master → `gh release create` →
  Linux 包由 CI 合并哈希行),以及"已发布的版本号不要复用"的理由。

其它:

- `.github/workflows/docs.yml`:推 master(`docs/**` / `package.json` / workflow 自身有变)即构建并
  部署到 Pages;构建带 `--check`,把 docfx 的警告当错误 —— 最常见的警告是"某个 `.md` 没被任何
  `toc.yml` 引用",那种页面有内容但没有侧边栏,属于必须修掉的疏漏;
- docs 目录重组后的引用同步:`production` / `mysql` / `linux-deploy` / `winisland-design-tokens`
  移到新位置后,AGENTS.md、`deploy/`、`scripts/`、客户端源码注释里的路径引用一并更新;
- 文档站只发布 `docs/` 这一棵树,页面里指向树外的相对链接(`../AGENTS.md` 等)改成 GitHub 绝对 URL,
  否则上线全是 404;
- 图标派生清单补上文档站模板里的 `logo.png` 与 `favicon.png`(`pnpm icons` 一并生成,
  仍然只有一个图形源 `build/classhelper.{png,ico}`);
- `docs/_site` 进 `.gitignore` / `.prettierignore` 与 ESLint ignores;
- 根脚本补 `version:check` / `version:bump` / `docs:build` / `docs:serve` / `docs:check`。
2026-10-06 16:27:44 +08:00

6.7 KiB
Raw Blame History

title, description
title description
更新与升级 检查更新与各形态的升级步骤、Linux 的升级回滚链路,以及升级前必须做的准备。

更新与升级

先知道版本是怎么回事

三端共用一套版本口径:

  • 版本号的单一来源是仓库根 package.json。服务端在运行时读它(打包后读的是运行时清单), 不在代码里写死;
  • 比较逻辑放在 @classhelper/shared 的 compareVersions / isNewerVersion,三端共用 —— 避免出现"客户端说有新版、服务端说没有";
  • 数字相同、只有后缀不同时,带后缀的算更新(对应 v0.1.0-fix 这种"同版本号的修复发布")。

检查更新

端 入口 检查路径
服务端 / Web 管理端 顶栏用户菜单 →「检查更新」 浏览器 → 服务端 GET /api/update/check → GitHub
桌面客户端 启动后自动一次(延迟 5 秒)+「设置 → 关于」里的「检查更新」按钮 主进程 → GitHub(不经后端)

两端的路径不同是被约束逼出来的:

  • Web 端不能直连 GitHub。服务端下发的 CSP 里 connect-src 只放行 'self' 与 WebSocket, 浏览器发往 api.github.com 的请求会直接被拦掉。走服务端转发还有个好处:所有管理员共享同一份缓存 (GitHub 匿名限流是 60 次/小时/IP)。
  • 客户端在主进程做。渲染进程的 CSP 与导航防线是安全模型里最要紧的一层, 不让它去连外部域名、解析外部 JSON。

"查不到"是设计内的结果

机房服务器与教室机器常常只有内网,请求会超时或失败。这时接口返回 ok: false + 一句人话 (「无法连接 GitHub,本机可能没有外网」),界面按"暂时查不到更新"呈现并给重试入口, 而不是弹红字报错。

失败结果同样进缓存 —— 否则断网时每点一次按钮都要白等一个超时。

细节 说明
缓存 两端各缓存 30 分钟;?force=1 绕过服务端缓存,但仅管理员生效(否则任意登录用户都能刷爆匿名限流)
权限 任何已登录用户都能查(信息来自公开仓库);force 除外
只提示一次 客户端启动检查发现新版才推提示;点「忽略此版本」记进配置,同一版本不再提示

更新只提示,不自动下载、不自动安装。安装包仍由人从 Releases 页面取,可用 SHA256SUMS-<版本>.txt 核对。

升级步骤

Windows 安装包

  1. stop.cmd 停止服务;
  2. 备份 data 目录;
  3. 运行新版本安装程序 —— 覆盖安装会保留原有 .env,JWT 密钥与端口设置不变, 用户不需要重新登录;
  4. start.cmd 启动。数据库结构如有变更,会在首次启动时自动补跑迁移。

如果升级后需要重新登录,说明 .env 被覆盖了(JWT 密钥变了),检查安装目录权限。

Linux

sudo classhelper upgrade --check            # 只检查有没有新版本
sudo classhelper upgrade                    # 升到最新版
sudo classhelper upgrade --version 1.2.0    # 升到指定版本
sudo classhelper upgrade --url ./classhelper-server-linux-x64-1.0.1.tar.gz --sha256 <哈希>   # 内网离线
sudo classhelper upgrade --url <包> --force # 强制重装同一版本

sudo classhelper rollback --list            # 看有哪些程序快照
sudo classhelper rollback                   # 回滚到最近一份(会问一次确认)

upgrade 的完整链路(任一步失败都不改动程序文件):

解析目标版本 → 下载 → 校验 sha256 → 备份数据与配置 → 快照当前程序文件 →
停服 → 替换程序文件(改名 + 就位,data/ 与配置原地不动)→ 起服 → 轮询 /healthz
   ↘ 失败:自动用刚才的快照回滚并重新起服,再告诉你失败原因

两点必须知道:

  1. 升级不会回滚数据库结构。如果新版执行过迁移,回滚程序前要确认旧版还能读新库, 必要时用 classhelper backup restore 连数据一起回退。
  2. 替换程序文件用的是"改名 + 就位"而不是删除重写:升级时正在运行的就是 bin/classhelper 自己, 必须先改名再放新文件,运行中的进程继续读旧 inode,否则 bash 会读到半个脚本。

Docker

docker compose pull
docker compose up -d

数据库迁移在启动时自动补跑。

手动 / 源码

拉新代码或替换免安装目录 → 重启服务端。启动时 db-bootstrap 会用账本表 _ch_migrations 对比已执行的迁移,只补跑缺的那些:

  • 全新安装:依次执行全部迁移并创建初始管理员;
  • 覆盖安装:只补跑账本里没有的迁移(已存在的表 / 索引自动跳过);
  • 已是最新:不做任何写操作。

日志里会明确写出「全新安装 / 升级安装」、应用了几个迁移、跳过了几个已存在对象。

客户端(学生端)

从 Releases 取新的 setup.exe 覆盖安装即可,配置在 %APPDATA%,不受影响。

如果你是在自己维护的机器上只替换了 releases/ 里的产物、而没有同步到安装目录, 用户打开的还是旧的 resources/app.asar —— 表现为"改了但界面不生效"。 覆盖升级时用 robocopy ... /E 推一遍,再对那个副本跑一次打包版冒烟确认。

ClassIsland 插件

必须先完全退出 ClassIsland(它会锁住 DLL),再覆盖插件,然后重启。 插件配置 Config\Plugins\<插件 id>\Settings.json 里存着服务器地址与设备令牌,别覆盖它。

升级前的准备清单

  • 备份数据(classhelper backup / 复制 data 目录 / mysqldump);
  • 记下当前版本号,必要时能回滚到它;
  • 挑一个没课的时间 —— 升级期间实时推送会中断;
  • 升级后确认 /readyz 是 200,并且客户端顶栏的实时通道显示"已连接"。

给维护者

打版本、出安装包、发 Release 的完整流程见版本迭代与发布。