为规范开发流程，提升整体工作效率，特制定本办法。
一、需求管理流程
需求人员提出Bug，步骤、结果、期望必须写明（方便重现，并直接作为测试用例使用），Bug生命周期开始，Bug状态为“激活”。统一指派给吴文军，由吴文军指派开发人员，并抄送张超、徐扬、刘小平。
需求人员提出需求，指派给徐扬组织评审小组讨论评审。
一个需求只能是一个独立的功能，不能将多个功能混在一起，以下情况会导致其中一个任务完成，但我们是按照需求上线，已完成的任务需等需求中其他任务完成才能上线。所以，需求要尽可能的独立，小粒度。 如任务#341已完成，但任务#340还在进行中，其实任务#341与#340并无关联，但须等待#340完成，按需求上线。
- 需求描述栏格式：
（1）场景或原因：请简要说明该需求的场景或原因。
（2）描述：使用清晰的语言阐述清楚，尽量用（主语+谓语+宾语）的语法结构，不要加入主观的修饰语句。 - 验收标准栏格式：尽量用量化的语句，无法量化的案例解释。
徐扬每周组织需求评审会议，根据评审结果完善需求，评审通过后将需求指派给吴文军，由吴文军分解为任务指派给开发人员，此时任务状态为“未开始”，测试人员开始编写测试用例。
需求评审分为两步：第一步：需求初审，确定需求实现思路，开发组长及开发人员需要参与。第二步：技术方案评审，需要测试人员参加，确定需求实现方案。为提高工作效率，简单需求不用召开全员评审会，相关人员线下评审即可。如果需要组织评审会，各职能组需先线下预评审，预评审后的文档才能用于会上评审，避免所有问题都在评审会上讨论解决，拉低评审会效率。
二、开发管理流程
- 开发人员必须每天登录禅道查看指派给自己的Bug或任务。
- Bug：判断是否存在该Bug，如存在请修改Bug状态为“已确认”，如不存在请打回给指派人并在备注中说明原因。查看方式如下：测试->Bug->指派给我。
- 任务：如启动开发，将任务状态修改为“进行中”。任务查看方式如下：项目->任务->指派给我。
- 开发人员修复Bug或完成任务后，且在开发环境自测通过后，须填写备注, 并修改Bug状态为“已解决”或任务状态为“已完成”，指派给张超，由张超指派测试人员测试。备注格式要求如下（必填，不填则不予测试）：
（1）改动的系统：系统中文名称（系统项目名称），如：控台门户（GZConsole）。
（2）关联系统：有/无，系统中文名称（系统项目名称），如：通知系统（notify-webapp）。
（3）数据库：
a. 是否有变更：有/无，有则需将SQL文本上传到任务附件，部署人员将按此文件变更数据库。
b. 执行时间：部署前/部署后。
c. 是否需要处理历史数据：是/否，有则需写入SQL文本。
（4）方案说明：Bug和任务都需要编写设计文档。说明原因，及解决问题的思路、方法，涉及页面的需要画出UI原型，评审通过的文档需上传附件。
（5）测试要点：简要说明需测试人员重点关注的点，如回归功能点、关联系统、特殊边界、性能指标等。
（6）代码审核人员：XX。
（7）上线说明：如关联系统上线顺序，历史数据处理，注意事项等。
开发人员应参照上线日期至少需预留出2天时间给测试人员在集成环境测试需求/Bug，否则可能影响上线进度，举例来说，周四上线的内容在周一就要部署到集成环境。
每名开发人员配备一名开发组长进行指导，开发组长同样对开发结果负责。设计方案需要考虑大数据、高并发、数据库I/O次数、缓存、系统间交互次数等性能问题。
三、测试管理流程
目前测试案例统一使用禅道用例管理。测试人员接收到任务或者Bug后，按要求编写测试案例，案例编写完成后，发给张超汇总，同时自己导入到禅道。
测试案例评审：测试前由张超组织讨论组（需包括开发人员）评审测试用例，通过后才能进行测试。
测试人员接收到指派后，在集成环境根据测试用例进行测试，并修改禅道测试结果，Bug测试不通过则修改状态为“激活”，任务测试不通过则修改任务状态为“进行中”，并备注原因打回给开发人员，同时提出集成bug，关联该任务。测试通过修改备注为“测试通过，可以上生产”，指派给张超。注意，测试除了需求任务/Bug内容外，还要对可能影响的主要功能进行回归测试。
测试环境任务/Bug测试通过后，指派给张超。
若某些功能测试环境无法进行测试，由张超发起评审会议。
四、SVN代码管理流程
开发人员在提交SVN时需要跟上任务（task）/Bug号及需求/Bug名称，格式如下：
（1） 任务：task #414控台-交易监控页面优化。
（2） bug：bug #2390支付系统同步调用日日结交易结果通知接口。
（3） 禁止无备注说明提交SVN。代码审核。
（1）开发人员在提交开发环境SVN后，在禅道将任务/Bug指派给代码审核人，发起代码审核流程。审核人收到指派后对代码进行审核，审核完成后将任务/Bug指回开发人员，通过则在禅道备注代码审核通过，否则备注代码审核不通过。代码必须审核通过后才能合并到集成环境SVN，测试人员在代码审核通过后才能测试。
（2）采用开发组长审核的方式。审核内容主要有代码逻辑、风格等。目前云平台的处理耗时绝大部分集中在数据库I/O操作，尽量减少对数据库的I/O操作，配置类等不经常变更的内容尽量放在缓存中。
代码风格参照：http://www.hawstein.com/posts/google-java-style.html#Naming
在多人开发同一系统或代码改过较大时，建议开发人员创建自己的开发分支，在分支上进行开发，避免造成代码混乱。
多个开发人员共同开发一个系统的情况，合并代码时应特别注意互相确认版本是否正确，指定一名开发人员作为系统负责人，作为该系统统一的出入口，对接各开发流程。
新增SVN生产代码分支，集成测试通过的功能，根据上线列表（由测试人员发布），预先合并到生产分支（各系统负责人按系统合并后回复上线列表邮件给张超，确定已合并上线内容到生产分支），等待上线。测试人员需至少提前一天在测试环境测试验证生产分支代码版本是否正确。避免多个功能混在集成分支相互影响，造成由于某个功能测试不通过影响其他测试通过的功能上线。
五、数据库操作流程
除上线外的生产数据库操作，需填写数据库操作申请表，命名格式“生产/集成数据库操作申请表-提出人姓名-日期”，见附件。电子版统一发送给阚普、杜华松，同时生产环境打印纸质版签名，集成环境不需打印签名。
六、测试环境部署流程
云平台测试环境分为：
开发环境：由开发人员部署，主要用于开发时自测联调?？⒒肪巢渴鹉厦扛稣憧嫉?0分钟为部署窗口，如需在其他时间部署，请在群里报备，报备格式为“开发环境+系统+部署，预计耗时X分钟?！保缥抟煲樵蚩刹渴?，部署不成功则立即回退，不能长时间影响开发环境稳定性。
集成环境：由测试人员统一部署，主要用于测试人员上线前测试。集成环境部署由张超统一部署，部署窗口为每日11:00-11:30，张超整理每日部署列表，开发人员需要在每日11点前将部署集成的任务或Bug发送给张超（上海也需要发送），部署后如严重不通过应立即回退。如有紧急部署请联系张超，禁止私自部署、重启集成环境。
七、生产上线流程
由张超根据测试情况统一发出本周上线列表，按照需求，bug上线。
生产上线开发人员需要填写上线申请表（命名格式：XX系统-上线申请表-上线日期YYYYMMDD）及变更SQL，格式见附件，请严格按照要求执行。在集成环境执行过的SQL要做好记录，为上线SQL做准备，防止遗忘。电子版申请表统一发送给阚普，抄送给徐扬、杜华松、刘小平、张超，同时打印纸质版签名，签名顺序依次为：开发人员、开发组长、测试人员、项目经理、实施人员、验证人员。注意，计划上线的需求/bug申请表需提前一天提出。
部署包由部署人员统一打包并上传到生产环境?？⑷嗽北匦爰觳樾薷墓拇?、配置文件、SQL脚本，如涉及数据库变更必须检查集成环境与生产环境数据库表结构、索引是否一致，避免版本错误、遗漏文件、数据库表结构等问题导致上线异常。
上线时开发组长需要轮流值班，开发组长：吴文军、李成成。上线前由张超提前一天拟出需要陪同上线的开发人员名单并说明原因，由开发组长确定陪同上线开发人员。
为防止上线版本对原功能的影响，定版待上线后，在集成环境进行全面回归测试，上线后在生产环境进行全面回归测试。
涉及关联系统变动的上线，需在上线申请表中说明上线依赖关系、部署顺序等。
验证人员在上线后根据上线列表逐一验证，验证通过，修改备注为“生产验证通过?！?，并修改任务/bug状态为“已关闭”；否则打回给张超，并修改备注“生产验证不通过，原因：XXX”，如果是任务验证不通过，需提出上线bug。
上线后统一由徐扬根据需求上线情况关闭需求。
