十年磨一剑!
一个中台管控系统的版本化管控方案:插件版本管理说明
- 插件系统说明
- 当前插件系统本身是一套责任链模式系统, 插件和插件间通过约定进行功能交互. 简单以库存同步为例, A插件只要约定库存同步规则, ERP只要按这个约定给到A插件, A插件就可以完成库存同步. 叠加套餐插件, 就ERP给数据到A插件, 套餐提取ERP数据, 处理完, 再按约定给到A即可实现套餐库存同步. 后续如果叠加虚拟库存, ERP给数据, 虚拟库存插件将计算结果按约定给到套餐或直接给到A插件, 最终实现库存上传. 订单同样, 通过订单状态约定, 可无缝切换波次, 快递鸟, 菜鸟裹裹等插件, 组成各种系统, 而系统只需维护好每个插件. 但同样的, 系统对插件设计要求会比较高, 任何功能需要经过合理安排, 检查和测试才能进来, 不然一个调整疏忽将可能蹦坏各种组合成的系统, 特别是系统插件等核心插件.
- 插件系统问题
- 原插件系统被设计成是做成类似”微擎”,”discuz”或”odoo”类的应用平台, 打算实现各插件独立版本化管控, 这样契合各平台接口对接, 也方便各平台独立管理, 升级, 便于未来做一个开放式平台做铺垫. 但随着时间推移, 现有系统已经形成插件组合模式的系统, 本质上, 该模式已和原设计的插件平台模式不同, 大部分插件已经通过组合, 形成一个插件组合系统而非插件独立管控形式, 单一插件出问题, 将影响到各种组合构成的系统. 而原管控模式, 包括SVN只设计了主线和分支管理, 没有实现一个主系统的版本的截断, 在持续开发迭代过程中, 容易出现因考虑不足, 导致系统不稳定, 特别是系统插件等核心插件的调整. 系统已经经过快速发展期, 现在需要进入稳定管控阶段, 所以需要实现一个版本截断和管理. 并有规划的进行版本升级, 不能只认一个主线即一个”版本号”.
- 原插件系统被设计成是做成类似”微擎”,”discuz”或”odoo”类的应用平台, 打算实现各插件独立版本化管控, 这样契合各平台接口对接, 也方便各平台独立管理, 升级, 便于未来做一个开放式平台做铺垫. 但随着时间推移, 现有系统已经形成插件组合模式的系统, 本质上, 该模式已和原设计的插件平台模式不同, 大部分插件已经通过组合, 形成一个插件组合系统而非插件独立管控形式, 单一插件出问题, 将影响到各种组合构成的系统. 而原管控模式, 包括SVN只设计了主线和分支管理, 没有实现一个主系统的版本的截断, 在持续开发迭代过程中, 容易出现因考虑不足, 导致系统不稳定, 特别是系统插件等核心插件的调整. 系统已经经过快速发展期, 现在需要进入稳定管控阶段, 所以需要实现一个版本截断和管理. 并有规划的进行版本升级, 不能只认一个主线即一个”版本号”.