POS发版流程

背景：

目前POS端医保、POS需求项目众多，管理相对复杂，需要制定详细流程避免发版过程中的风险。

目标：

将POS灰度和上线流程规范化，按步骤进行，避免步骤遗漏和风险防范措施缺失。

全量配置规范

	内容	操作详细	对接人	风险防控	紧急停止方案
	内容	操作详细	对接人	风险防控	紧急停止方案
1	确定发版代码	1 、灰度池灰度完成后，开发、产品、测试同时确认（避免医保和POS功能未同步）线上最新版本内容，确认最近全量版本是否已合并master。 2 将最新master代码合并进入新版中。 3 新版包打包完成，开发需要邮件周知本次打包的开发分支，是否合并最新master分支，合并master分支后的版本号等内容提交给QA回归；每次bugfix后，需要周知修改内容及影响范围。 4 QA对新版进行回归并周知结果。	开发：扁竹(张立奎) 产品: 钟离无言(韩丹丹) 稻牙(张月姣) QA：@田川	如果未全量版本已合并进入master，需要操作master回滚。 已全量版本未合并master.需要开发确认后合并全量版本的内容进入master.
2	新版过白	确认某新版（ v4.2.5.1） 回归完成，QA发送邮件申请过白	过白申请：QA 过白操作：张志杰
3	过白后灰度	灰度的总数量要达到800家，充分灰度 灰度过程中发生的POS端问题，都需要记录，并确认跟进到问题解决，不解决的问题需要同步   扁竹(张立奎)   生地(田星海)	QA	灰度过程发生用户投诉，应该迅速解决。 能快速解决的，在该灰度池加应急版本，静默升级解决 不能快速解决的，需要将用户 移出灰度池，修改用户本地编号，引导用户升级 强烈建议有一键恢复上一个稳定版本的功能，这样移出后客户能自己修复
4	ftp上传	版本过白后，开发负责将对应版本 （ v4.2.5.1）的压缩包上传到ftp文件服务器	开发		如果线上某版本v4.2.5.1发生大量报错、用户投诉，可以在该版本全量配置删除后，将 v4.2.5.1 的问题包删除（备选方案）
5	线上全量配置	发全量前一天（比如28号全量，27号邮件发出），QA需要将灰度过程、灰度结果，灰度问题是否处理完成等信息邮件周知开发、测试、产品，确认是否可以发全量。 QA在晚上22：00后，配置全量发版的版本号 （ v4.2.5.1） 、版本 支持 最大编码，版本支持最小编码，ftp url等信息后，配置全量发版	QA 生地(田星海) 扁竹(张立奎) 石胆(谭秉华) Micheal(赵祥祥) 钟离无言(韩丹丹) 稻牙(张月姣)	版本号、版本最大编码，版本支持最小编码信息非常关键，一定要细心核对	线上某版本v4.2.5.1发生大量报错、用户投诉，第一时间止损措施为删除该版本（v4.2.5.x）的全量配置项，避免仍然有增量用户升级。 已升级用户的问题如果短期开发无法定位并解决，需要引导用户再次升级到上一个稳定版本。 --具体操作为： 将上一个版本稳定版本版本号 v4.2.5.0 变更为v4.2.5.x(x=现在灰度池的数量+1) 将pos包中的编码+x 将新包上传ftp 配置 v4.2.5.x的全量配置项，让有问题用户再次升级。
6	全量后合并master	本次全量一天（？）后，无线上事故、无线上问题的前提下，由开发发起本次版本合并master分支	开发：开发主R 产品: 钟离无言(韩丹丹) 稻牙(张月姣) QA：@田川	合并前需要周知医保以及pos开发、测试以及产品

 

按周期迭代制

 

背景：

• POS涉及医保、销售等多需求并行开发，造成POS的并行版本多
• 多版本基于不同的基础版本开发、版本合并会造成多次的回归，放大版本风险
• 发版没有规律，容易造成排版本、合并版本上的困难
• 多次造成代码遗漏

 

目标：

• 发版周期固定，上线后即合并master，产研业务有明确的上线时间预期。
• 一个版本周期内均基于一个共同的基线版本开发，每次上线回归1次
• 通过规范化的流程避免代码遗漏

 

措施：

现状：

（1）PM拿到需求时，往往自己也无法完全明确所有的细节，只有有一点是明确的，这个需求必须要上。

（2）下游的QA团队他们，只希望留有足够的缓冲时间，去测试，不要一下子在短时间过来大量的需求；

（3）一线开发的RD希望，到自己手上的需求是明确的，不能充满不确定性，模糊性，后端等资源也要明确；

 

改进总体原则为：评审、开发、测试完全并行，以两周为固定周期，以需求维度持续交付。

• 针对问题，屏蔽掉各个需求开发迭代节奏，不再遵循按需求周期上线
• 只需要关注POS的提测和发布时间点即可。让PM有需求就每周提一次过来，如果评审通过（PRD明确），就加入需求池中，
• 如果需求所需要的资源明确之后，我们直接从需求池中移除，分配给对应的RD去开发；
• 形成两周发版的节奏