24 lines
3.0 KiB
Markdown
24 lines
3.0 KiB
Markdown
# V2 开发、固化与验收
|
||
|
||
本项目固定使用私服发行的 Core 8.1.0、Module Runtime 9.0.4 和 RPC 9.0.7；精确依赖、锁文件与逐文件校验基线一并提交。
|
||
|
||
配套控制面使用 SaaS 9.2.0 的签名构建、自动验收、独立批准与证据撤销接口。
|
||
|
||
健康的 locked RC 仍可直接推送 development/test 租户。正式发布采用下面的顺序。
|
||
|
||
1. 在平台锁定 Build，用 CLI generate 获取精确候选分支及生成文件。
|
||
2. 使用 `pnpm exec cool saas-model dev --watch` 开发。只替换本进程拥有的 generation；构建错误、依赖变化、平台停用不会让旧身份运行新代码。
|
||
3. 结束开发，停止 watch，提交并推送候选分支。
|
||
4. 使用 `pnpm exec cool saas-model finalize --builder-config <外部绝对配置路径>`。配置必须提供独立 Ed25519 builder 身份、平台任务公钥及外部 artifactRoot。CLI 从 Git 提交提取源码、独立复制实际 node_modules，然后测试和构建；源码、启动脚本及依赖在构建后被改写则拒绝固化。
|
||
5. 保存 CLI 输出的 frozen deployment directory。平台保留已签名的 bundle，包含 dist、启动器、候选锁、依赖锁，以及每个已安装依赖文件和链接目标的清单。不要在部署时再次安装依赖或构建。
|
||
6. 在这份目录设置精确 Release ID、BUILD_SHA、独立 Runtime state/ticket/租户凭证、`SAAS_RELEASE_TRUST_FILE` 外部 builder 公钥信任文件与短期制品读取凭证，运行 `pnpm start:frozen`。任何文件与签名制品不一致都必须先处理，再启动。
|
||
7. 平台创建验收任务；专用 runner 执行固定的授权、业务、进程恢复套件，签名提交不可变报告。正常角色账号必须预先准备；中途改菜单、权限、路由、数据库连接或安装代次会使本次验收失效，恢复旧值也不能消除变化记录。
|
||
8. 管理员查看报告，选择有效 run 单独批准，然后晋升 Stable。浏览器人工填写通过结论不能替代自动报告。
|
||
9. 使用同一份 frozen deployment directory，切换为 Stable 的独立运行身份并运行 `pnpm start:stable`。启动器读取当前控制面证据及撤销状态，复核可信 builder 签名和完整本地字节，再验证 Runtime bootstrap 的精确身份。
|
||
|
||
响应丢失时，保留 build-task.json、freeze-submission.json 与 deployment。使用 `finalize --resume-submission <原提交文件的外部绝对路径> --builder-config <原配置>` 重传完全相同的固化请求；它不重新构建、签名或申请任务。只有原任务、源码、远端 Tag、签名和字节均一致时才允许重试。
|
||
|
||
task issuer、builder、runner 使用不同密钥。私钥和控制面凭据不得进入 Git、npm 或部署 bundle。执行器及其启动入口属于信任边界；独立构建目录不等同于操作系统沙箱。历史 V1 记录只走显式兼容流程，不能伪造为 V2 自动验收证据。
|
||
|
||
本项目的启动器测试属于本地校验；真实租户业务验收由平台的独立 runner 执行并保存报告。
|