流程概括:
需求收集 -> 领导层产品讨论会 -> 需求评审会 -> 工期确定会 -> 详细设计 -> 提测 -> 测试 -> 发版评审会 -> 发版
需求收集:
功能需求,产品优化,技术优化,bug等均需要收集,其中技术优化不要自行优化,要汇报到技术总监处,bug由测试收集,最终全部收集到产品处;
过程中,产品设计具体产品方案,技术事先调研技术方案;
领导层产品讨论会:
收集后,由产品组织会议与公司领导确定优先级,方案取舍,初步定下发版时间
需求评审会:
产品组织,由各组组长参会,理解需求,讨论方案,提出问题;
由于会对方案进行改进整理,该会可能会有多次;
会议确定最终研发任务列表和版本号
工期确定会:
就新版覆盖范围,各组进行分工,估算开发时间,测试时间,多组协调估算最终工期,最终确定发版时间;
注意要包含产品和UI时间
详细设计:
各开发组长带领组员对具体需求进行详细设计,并逐一确定实现方案(包括代码主要技术点和逻辑),防止开发个人决定的方案太粗糙导致bug太多降低效率、埋下隐患;
测试制定测试计划,设计用例,测试方案,并开展计划和用例评审会;
测试评审会需要产品、技术、测试一起参加,完善测试计划、用例和方案,比如隐藏逻辑、技术点、老数据兼容等;
提测:
各组组长发提测邮件给测试组并抄送技术负责人和相关产品,将要测试的内容说明
管理后台有影响到前台功能的也要提测,并说明测试点
测试:
运维配合测试配置新版测试环境(如jenkins,数据库等),测试从版本分支上部署代码到测试环境;
测试就提测内容进行测试,测试不通过的由开发修改后再次提测;
最终在测试环境测试通过后,测试与开发组长配合将版本代码合并到版本对应的预发布分支,并由测试和运维配合将代码部署到预发布环境;
注意:影响前台功能的务必通过联合测试
发版评审会:
版本对应内容在rc环境测试通过后,测试组长发邮件给相关技术人员,产品和技术负责人,发起发版评审会;
相关负责人,各组组长参会,会上主要讨论要发版的各项服务,要讨论每个要发布服务和相关服务可能产生的问题,并确定发版方案,比如每个服务如何发版,如何回滚,是否需要灰度发布,何时发布,何人在场等;
原则上发版时间应避开流量高峰时段发布,相关开发和测试人员应在场;
每次根据会议内容,结合历史经验,务必整理一个发版文档,发版时按发版文档操作;
发版:
无论前后端的发版都需要测试组经过test环境和rc环境的测试;
根据发版评审会通过的发版方案进行发版;
发版后进行回归测试,通过可视为发版成功;
有紧急问题,如可很快修复可立即修复,不能短时间修复的立即执行回滚方案,回滚后,回归验证通过,视为发版中断;
中断的发版需讨论后决定重试或者择期再发。