LoveChengke
19c2aa07b2
文档站（`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`。
133 lines
6.7 KiB
Markdown
133 lines
6.7 KiB
Markdown
---
|
||
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](https://github.com/LoveChengke/classhelper/releases)
|
||
页面取，可用 `SHA256SUMS-<版本>.txt` 核对。
|
||
|
||
## 升级步骤
|
||
|
||
### Windows 安装包
|
||
|
||
1. `stop.cmd` 停止服务；
|
||
2. **备份 `data` 目录**；
|
||
3. 运行新版本安装程序 —— 覆盖安装会**保留原有 `.env`**，JWT 密钥与端口设置不变，
|
||
用户不需要重新登录；
|
||
4. `start.cmd` 启动。数据库结构如有变更，会在首次启动时自动补跑迁移。
|
||
|
||
如果升级后需要重新登录，说明 `.env` 被覆盖了（JWT 密钥变了），检查安装目录权限。
|
||
|
||
### Linux
|
||
|
||
```bash
|
||
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
|
||
|
||
```bash
|
||
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 的完整流程见[版本迭代与发布](../dev/release.md)。
|