我们项目组的客户端多大20余种，两年前为这些客户端写了一个升级模块，但是不够强悍。去年年中重新做了一个客户端灰度升级系统，一个独立的系统专门为客户端升级提供服务。现在分享下这个新系统的升级策略。
发布版
每种类型的客户端有且仅有一个对外发布版。版本号比发布版低的客户端都要升级到发布版。在客户端层面的升级形式有两种，登录升级和使用中升级。
1.登录升级
登录前提示升级，一般是比较重要的升级方式才会配成登录升级。用户当然可以取消升级，但是如果旧版本配的是强制升级，那么登录升级就不会展示“取消”按钮。这个是系统的后门，防止有重大问题的客户端被使用。一旦出现这种情况，这个功能将是一根救命稻草。（我们线上某个版本的移动端3天内耗了用户4G流量，可惜它没有接入这个系统）
2.使用中升级
如果提供了补丁包，那么升级将在后台静悄悄的发生，用户不会感知到升级过程。如果提供的只有全量包，那么新包下载好后，下次重启时将会安装发布版。
为了灵活控制对外发布版的升级，发布版可以按百分比升级，按用户名升级，或者全量升级。
旧版本
老的版本有三种升级方式，1.强制升级，2.非强制升级，3.不升级。
有些版本线上表现稳定，如果冒然升级，可能引发问题，因此提供这个升级选项。
如果版本有问题，或者太旧，就提供强制升级选项，必须让用户升级。
如果版本没有重大问题，跟新版本比较，可能仅仅缺少一些功能，那么提供非强制升级。用户如果不想升级，那么就cancel掉。
内测版
客户端版本包正式发布前，必须内测。以前我们遇到一个案例，一个有问题的包，没有内测，发出去后，就出大问题了。因此内测成为了客户端发包的一个基本流程（尤其是重要客户端）。如何获取内测包，给内测用户一人一个下载地址，让他们下下来然后把老的卸载，新的安起？NO，内测升级高于发布版升级，只要内测升级的名单列表里有的用户，会自动升级到内测版。内测升级还有另外一个策略，按百分比升级。全量正式对外发布前，可以设置一个百分比，根据灰度算法，会有一定比例的用户升级到内测版。
每种产品各自维护自己的产品线升级策略，互不干扰。
版权声明：本文为博主原创文章，未经博主允许不得转载。