上文中，由于初次接触灰度发布，关于这一概念的践行还有很多不了解的地方，因此标题为“灰度发布用户选取”。后来在进一步的了解中，逐步意识到，灰度发布不仅仅需要关注用户群体，关于用户特征、发布的方案、策略等等，其实有很多的方面需要细细考虑。因此灰度发布其实应该有一个完整的方案。
灰度发布的方案，大致包括如下内容：发布目标、发布策略以及用户筛选。
发布目标可以有多个，如测试新功能以获取用户反馈、比较一个功能点两个设计/实现方案的合理性/优劣性（A/B测试）、推广等多种目标，一般而言选择一个目标即可，多选可能达不到既定的目标。
发布策略，涉及到用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略。这里想提及一下当前的项目需求--计划建设一个通用的管理系统用于管理当前的全部项目，其中部分项目有“灰度发布”的需求，上一篇文章中也曾提及想要选择一个“普适”的方案，但是就发布策略而言，每个项目的特征决定了发布策略，因此难以做到“普适”的方案。但是由于当前项目组的用户范围十分稳定，“普适”的策略依然有一定的可行性，这一part还需要和开发团队的小伙伴一起商量。如果“普适策略”可行，为了践行项目的特征希望达到的差异性，可以在用户筛选中选择不同的用户筛选方式--说到这里感觉自己已经被说服了，美滋滋。
用户筛选，希望新老用户能够同时参与（对于我们目前的项目而言，新用户十分难以进行把控）。度娘上找到的灰度发布用户筛选方案几乎都是通过流量控制/渠道控制来实现，但是对于小型的互联网应用而言，流量/渠道其实十分单一，很难达到控制的效果。因此依据项目的特性，目前暂定以下方案：维护用户列表并且增加“灰度”字段，项目需要使用灰度发布时，管理员通过随机勾选or用户设备编号最末位是数字且不小于5（按照项目的实施来决定用户的占比，一定程度上实现新老用户的同时参与）来实现用户筛选。
目前的用户规模：峰值为1200，日活在50-100之间；发布频率暂时不稳定，频繁时期一周一次，非频繁时期一月一次；不存在A/B测试，功能开发一般仅开发一个版本，因此功能覆盖度可以有效掌控；回滚策略，由于低版本无法覆盖高版本，拟将灰度测试的安装包版本号加以字母“X”作为标记，如需回滚，则将前一个版本的代码作为新版本的资源并且标记为回滚版本；新旧系统部署策略，暂时我了解到有两种方案：发布一套后台兼容新旧应用，或者新旧后台独立部署，两种部署方案目前我们会采用第一种方案。
今天暂时了解了这么多内容，一边记录一边帮助自己理清思路，美滋滋，最后的结论也出来了==
网友评论