版本、发布与变更管理

本章目标：理解设计中的修改如何影响正在使用的应用，建立可追踪、可验证、可恢复的发布方式。

1. 保存不等于发布

业务开发通常有两个不同动作：

• 保存设计：保留当前修改，供开发者继续调整；
• 发布版本：把一版经过检查的设计交给业务用户使用。

不要把每次试验性修改立即变成用户正在使用的版本。发布意味着这一版已满足明确的业务范围与验收条件。

模板版本操作参见模板版本管理，流程版本参见流程发布与版本。

2. 给版本一个业务说明

不要只记录“v2”“修改了一些问题”。

推荐说明：

1.1：增加采购申请退回原因；退回后申请人可修改并重新提交；修正总金额等于 5000 元时错误进入高级审批的问题。

每个版本记录：

• 发布日期；
• 业务负责人；
• 应用开发者；
• 变更原因；
• 新增、修改和移除内容；
• 影响角色；
• 影响数据、动作、流程、权限、视图和输出；
• 执行过的验收场景；
• 已知限制。

3. 变更分为四类

3.1 内容变更

提示语、说明、布局微调。通常风险较低，但仍需检查用户是否误解。

3.2 规则变更

金额边界、校验、计算和操作条件。会影响业务结果和测试。

3.3 结构变更

新增、修改或删除字段和明细。可能影响已有记录、动作、视图、打印和统计。

3.4 流程与权限变更

处理人、节点、角色和数据范围变化。可能影响在途业务和数据可见性，风险通常最高。

不同类型不能使用同一套轻量检查。

4. 变更前做影响分析

例如把“预计单价”改为非必填：

• 总金额怎样计算；
• 高金额流程怎样判断；
• 待采购视图是否仍能排序；
• 审批人是否有足够信息；
• 导出和打印是否允许空值；
• 已有记录是否受影响；
• 哪些测试需要更新。

影响分析清单：

• [ ] 数据和历史记录；
• [ ] 表单和操作；
• [ ] 计算与动作；
• [ ] 流程条件和在途记录；
• [ ] 角色与权限；
• [ ] 视图、指标、导出和打印；
• [ ] 通知和定时工作；
• [ ] 培训与使用说明；
• [ ] 验收场景。

5. 特别谨慎对待破坏性修改

高风险操作包括：

• 删除已有字段或明细；
• 改变字段业务含义；
• 把一种类型改成不兼容类型；
• 删除仍在使用的流程或视图；
• 大幅收缩或扩大数据权限；
• 改变流程边界而不处理在途申请。

执行前：

1. 确认真实目的；
2. 检查已有记录和引用；
3. 确认历史查询是否仍需要；
4. 备份或保留可恢复版本；
5. 在独立验证范围先试；
6. 得到有权决定人的明确确认；
7. 准备失败后的恢复步骤。

“界面上暂时不用”不等于可以删除。

6. 处理在途业务

修改流程时必须区分：

• 已经提交、正在处理的申请；
• 尚未提交的草稿；
• 发布后新提交的申请。

通常更容易解释的做法是：

• 在途申请继续按原版本完成；
• 新提交申请使用新版本；
• 草稿提交时按新规则重新检查；
• 若必须迁移在途申请，单独制定业务处理方案并逐条确认。

不要让已审批一半的申请因为新版本突然改变下一处理人。

7. 发布前检查

配置检查

• 设计已保存并重新进入确认；
• 临时测试名称和说明已清理；
• 必须规则已配置；
• 正式角色和数据范围明确；
• 流程已发布并正确用于模板；
• 正式视图和入口可见。

业务检查

• 正常、边界和异常场景通过；
• 各角色允许和拒绝操作通过；
• 保存后重新打开正确；
• 退回、撤回、拒绝和作废正确；
• 管理指标口径核对；
• 导出、打印和通知按范围验证。

交付检查

• 版本说明完整；
• 业务负责人知道变化；
• 受影响用户收到说明；
• 初始数据和角色已准备；
• 问题反馈负责人明确；
• 恢复方案可执行。

8. 小步发布

对于较大变更：

1. 先选代表性小范围；
2. 使用接近真实的数据；
3. 让目标角色完成核心业务；
4. 观察一段真实使用；
5. 修正高优先问题；
6. 再扩大范围。

小步发布不是降低质量，而是在影响范围可控时获得更真实证据。

9. 发布后的立即验证

发布完成后不要只看“发布成功”：

• 用普通用户账号进入；
• 创建一条最小正式样例；
• 保存并重新打开；
• 提交并检查正确待办；
• 用审批账号处理；
• 查看状态和角色视图；
• 检查通知和输出；
• 验证未授权账号仍被拒绝。

如果有任何关键结果不符合预期，停止扩大使用范围。

10. 变更请求流程

上线后新需求建议经过：

提出 → 说明业务问题 → 分析影响 → 决定优先级
→ 更新蓝图 → 开发和测试 → 发布 → 观察

变更请求至少包含：

• 当前问题；
• 受影响角色和场景；
• 期望结果；
• 是否有时间要求；
• 对已有数据和在途业务的影响；
• 谁负责确认。

不要直接根据一句聊天消息修改正式规则。

11. 回退与恢复

发布前就要知道：

• 可以恢复到哪个版本；
• 恢复会影响哪些新产生记录；
• 数据结构变化是否能够直接恢复；
• 流程已经产生的新任务怎样处理；
• 谁有权决定回退；
• 回退后需要重新验证哪些场景。

恢复版本不一定能自动撤销已经发生的业务事实，因此高风险变更更需要小步验证。

12. 常见错误

• 保存后立即发布，没有独立检查；
• 版本说明只有“优化”；
• 改字段时不检查流程、视图和打印；
• 新流程直接影响在途申请；
• 删除“暂时不用”的字段；
• 发布后只用管理员账号看一眼；
• 没有恢复方案；
• 根据口头要求直接修改正式规则。

13. 本章完成标准

• [ ] 保存与发布责任清楚；
• [ ] 每个版本有业务可读的变更说明；
• [ ] 变更已经按内容、规则、结构、流程权限分类；
• [ ] 发布前完成跨数据、动作、流程、权限和视图的影响分析；
• [ ] 破坏性修改有确认、备份和恢复方案；
• [ ] 在途、草稿和新提交业务的处理规则明确；
• [ ] 发布后使用目标角色走过完整业务；
• [ ] 新需求经过正式变更流程。

下一步

开发和发布准备完成后，需要证明应用在真实业务中正确、可用且安全。下一章学习用真实业务场景测试应用。