53 lines
2.2 KiB
Markdown
53 lines
2.2 KiB
Markdown
# I-02 · Gitea CI + 定时备份演练
|
||
|
||
| 字段 | 值 |
|
||
|---|---|
|
||
| 项目 | 基础设施 · Gitea（gitea.mymoyu.top）+ 四项目仓库 |
|
||
| 优先级 | P1 · M4 |
|
||
| 建议模型 | deepseek-v4-flash（主）/ glm-5.3-flash（复核） |
|
||
| 依赖 | 无 |
|
||
| 预估 | 2 天 |
|
||
|
||
## 一、背景（为什么做）
|
||
|
||
四个项目全部裸奔：**无 CI、无备份演练**。服务器只有自建 Gitea（gitea.mymoyu.top）。每次改动靠手工跑测试——这正是"多模型协作"最大的风险点：模型交付说全绿，但没人自动复核。
|
||
|
||
## 二、目标（交付物）
|
||
|
||
**A. Gitea Actions CI（每项目一个 workflow）**
|
||
1. `chunyu`: 后端 `manage.py test` + 前端 `npm run build`
|
||
2. `english-drill`: `pytest`（后端）+ E2E `run_e2e.py`（ASGI 模式）
|
||
3. `dealerhub`: `pytest -q` + 前端 `npm test`/`npm run build`
|
||
4. `dsp`: `pytest`（后端）
|
||
5. 触发：push / PR；失败必须真实失败（不 continue-on-error）
|
||
6. 缓存依赖；单 job 超时限制
|
||
|
||
**B. 备份方案 + 演练**
|
||
7. 备份脚本：PostgreSQL `pg_dump`（各项目库）+ 关键 `data/` 目录 + 配置（脱敏）→ 归档 + 校验和 + 保留策略（如 7 日轮转）
|
||
8. 恢复脚本 + 演练文档：**至少完成一次真实恢复演练**（空库恢复 → 启动验证），记录耗时与坑
|
||
|
||
## 三、验收标准
|
||
|
||
- [ ] 四个仓库各有一个可用的 Gitea Actions workflow（附一次真实运行的日志/截图说明）
|
||
- [ ] CI 对失败用例真实报红（用一个故意失败的临时 commit 验证后还原，或单元自证）
|
||
- [ ] 备份脚本产出带校验和的归档；保留策略生效
|
||
- [ ] **恢复演练完成**：从备份恢复到可运行状态，全流程记录（时间、命令、结果）
|
||
- [ ] 文档：`infra/README.md`（CI 说明 + 备份/恢复手册）
|
||
|
||
## 四、验收命令（参考）
|
||
|
||
```bash
|
||
bash infra/backup.sh # 产出归档 + .sha256
|
||
bash infra/restore.sh <archive> # 恢复演练
|
||
```
|
||
|
||
## 五、边界（不许做）
|
||
|
||
- 备份产物不含明文密钥（脱敏或排除）
|
||
- 不在 CI 里跑需要私有凭据的部署
|
||
- 不改各项目业务代码（只加 CI/基建文件）
|
||
|
||
## 六、交接
|
||
|
||
写 `PROGRESS_I-02.md`（含 CI 运行证据、恢复演练记录、归档示例校验和）。
|