区域教育应用中心建设的心得

应用得有版本有插件;

版本:大版本 ,小版本, 定制版

场景如下:
1.A开发商在应用中心上架了一个应用, 安装给部分学校单位了;
2.使用一段时间后, B学校提了一个需求, A开发商迭代了一个新版本; 想要上架;
此时有三种操作可能

一. 重新上架一个应用
重新上架一个应用 , 应用中心就会有俩个此应用, 这样显然不符合初衷, 也不友好; 长此以往的迭代, 应用中心惨不忍睹;

二. 覆盖原应用上架
覆盖原应用上架, 强制其他学校也升级, 这样做相对于让所有学校接受了B学校提出的需求, 不符合实际场景; 很简单如果有奇葩学校提的需求很奇葩, 但又不得去响应; 这个时候就得业务定制了; 如果让业务参与定制, 还在产品主线里, 那业务就会越来越臃肿;

三. 在应用下增加不同版本
应用还是原来的应用, 只是每次迭代都有不停版本;
3.1 修复型版本小版本迭代, 做到向下兼容;
3.2 新增功能版本为中版本发布, 一般会提供上一版本到新版的升级操作(可以理解也下兼容啦);
3.3 大版本的迭代如架构调整, 业务逻辑调整, 此时可能就不兼容了; 一般这种情况需要提供有感升级, 如:提供界面让用户自己升级到新版本, 这类升级大多数在开发时需要专门立项;
3.4 定制版 复用极低的功能, 一般应对对接功能, 奇葩需求;

最好可以做到小版本应用可以升到高版本;

应用插件

非核心功能的扩展有俩种做法; 一种是走定制版本来处理; 还有一种我们可以做插件的形式实现; 比如我们可以在应用基础上面,延伸出插件的概念, 把一些定制的可复用的非业务核心的功能,做成应用插件, 让有需求的客户, 自行选择安装;
走定制版还是走插件关键看功能的复用度与业务边界;
应用插件: 复用, 非核心功能
定制版: 复用极低, 业务奇葩

应用得有依赖

应用