发布与上线验收
完成正式包导入、发布状态和用户交付检查。
本页目录
上线从最终文件开始#
本章验收的是准备发给用户的实际加密组件包，而不是源码目录。源码测试和开发版集成通过后，仍需在目标正式宿主中完成这一轮。
先确认打包与登记已经完成，保留最终包、发行记录和测试资料。
第一步：检查发行信息#
| 字段 | 必须一致的对象 |
|---|---|
| ID、类别、版本 | 清单、后台记录与实际包 |
| 内容摘要与大小 | 本地最终文件与发行登记 |
| 宿主要求 | 实际调用接口与声明的最低版本 |
| 授权范围 | 业务计划与后台核验结果 |
| 发布状态 | 当前后台状态与用户可见入口 |
不要在核对完成后再改文件。发生内容变化，应作为新发行内容重新生成和登记。
第二步：首次导入#
在独立测试数据环境中，使用软件现有组件导入入口，选择与类别对应的 .mrite-task 或 .mrite-component 文件。兼容入口可能还支持旧 .mrite-plugin，但新包应遵循当前分类发行流程。
核对显示名称、图标、类别、版本、安装结果和打开状态。不要将源码 ZIP 改名后作为这个步骤的输入。
第三步：完成一个真实最小流程#
- 效率插件：打开、执行一项操作、查看结果，需要时保存到允许位置。
- 自动化任务：检查输入、运行阶段、取消或完成，核对实际文件。
- 两类组件：关闭、重新打开、停用再启用，检查清理。
- 需要模型、工具或文件能力的组件：分别核对实际配置和调用，不能只看界面出现。
第四步：验证拒绝和失败路径#
| 场景 | 预期 |
|---|---|
| 包损坏或内容不一致 | 明确拒绝，不留下半装配状态 |
| 类别或格式不匹配 | 明确提示，不靠后缀混用 |
| 宿主版本不足 | 告知版本要求，而不是空白加载 |
| 账号或授权范围不满足 | 明确解释，不能误报成功 |
| 网络或服务不可达 | 说明阶段和重试方式，保留用户项目 |
| 依赖或输出路径异常 | 指出对应对象和可采取的下一步 |
使用受控测试材料验证失败，不破坏用户正常项目或真实发行记录。
第五步：从旧组件升级#
使用上一受支持版本创建一个小项目，保留其材料、输出和设置。导入新版本后核对入口身份未变、旧项目可打开、状态迁移正确，并完成一次继续修改。
如果新功能需要升级宿主，更新说明应直接写出最低要求。不能在用户拿到插件后才让其发现宿主缺少接口。
第六步：确认可用的发布入口#
后台登记、发布状态、下载地址或人工分发是不同环节。维护者应核对实际后台支持的状态，并配置相应更新信息；需要 QQ 群或其他方式发包时，发出的仍是已验收的最终文件。
不要把“生成了本地包”“上传了文件”和“用户已经收到更新”当成同一件事。
上线交付清单#
- 发行文件及其摘要、大小和唯一记录。
- 组件与宿主版本、适用范围、依赖说明。
- 已运行的正常和失败用例记录。
- 用户可理解的变更内容、安装或更新方法。
- 问题收集与撤回方案，以及旧项目的处理约定。
完成这些步骤后再对外发布。上线后根据实际问题记录跟进，不为临时修复覆盖已发布同版本文件。