项目研发流程

流程概括：

需求收集 -> 领导层产品讨论会 -> 需求评审会 -> 工期确定会 -> 详细设计 -> 提测 -> 测试 -> 发版评审会 -> 发版

需求收集：

功能需求，产品优化，技术优化，bug等均需要收集，其中技术优化不要自行优化，要汇报到技术总监处，bug由测试收集，最终全部收集到产品处；
过程中，产品设计具体产品方案，技术事先调研技术方案；

领导层产品讨论会：

收集后，由产品组织会议与公司领导确定优先级，方案取舍，初步定下发版时间

需求评审会：

产品组织，由各组组长参会，理解需求，讨论方案，提出问题；
由于会对方案进行改进整理，该会可能会有多次；
会议确定最终研发任务列表和版本号

工期确定会：

就新版覆盖范围，各组进行分工，估算开发时间，测试时间，多组协调估算最终工期，最终确定发版时间;
注意要包含产品和ＵＩ时间

详细设计：

各开发组长带领组员对具体需求进行详细设计，并逐一确定实现方案（包括代码主要技术点和逻辑），防止开发个人决定的方案太粗糙导致bug太多降低效率、埋下隐患；
测试制定测试计划，设计用例，测试方案，并开展计划和用例评审会；

测试评审会需要产品、技术、测试一起参加，完善测试计划、用例和方案，比如隐藏逻辑、技术点、老数据兼容等；

提测：

各组组长发提测邮件给测试组并抄送技术负责人和相关产品,将要测试的内容说明
管理后台有影响到前台功能的也要提测,并说明测试点

测试：

运维配合测试配置新版测试环境（如jenkins，数据库等），测试从版本分支上部署代码到测试环境；
测试就提测内容进行测试，测试不通过的由开发修改后再次提测；
最终在测试环境测试通过后，测试与开发组长配合将版本代码合并到版本对应的预发布分支，并由测试和运维配合将代码部署到预发布环境；
注意:影响前台功能的务必通过联合测试

发版评审会：

版本对应内容在rc环境测试通过后，测试组长发邮件给相关技术人员，产品和技术负责人，发起发版评审会；
相关负责人，各组组长参会，会上主要讨论要发版的各项服务，要讨论每个要发布服务和相关服务可能产生的问题，并确定发版方案，比如每个服务如何发版，如何回滚，是否需要灰度发布，何时发布，何人在场等；
原则上发版时间应避开流量高峰时段发布，相关开发和测试人员应在场；

每次根据会议内容，结合历史经验，务必整理一个发版文档，发版时按发版文档操作；

发版：

无论前后端的发版都需要测试组经过test环境和rc环境的测试;
根据发版评审会通过的发版方案进行发版；
发版后进行回归测试，通过可视为发版成功;
有紧急问题,如可很快修复可立即修复，不能短时间修复的立即执行回滚方案，回滚后，回归验证通过，视为发版中断；
中断的发版需讨论后决定重试或者择期再发。