CQ单处理模板

1． CQ的提交
故障的提交，要方便于故障分拣和定位。
变更主题：[模块名称]内容简要描述。举例：[性能统计]任务创建失败。
变更描述：
环境说明：平台版本；对接版本；发生问题的环境配置说明（设备情况；数据库情况；第三方软件情况）；
故障现象：仔细描述故障产生的结果和反映。如果能力达到的话，说明可能的原因分析。
故障重现方法：说明故障是否可以复现，如果可以复现，描述复现的步骤。
附件：问题不好说明的情况下，附加故障现象截图、操作录像或者相关的日志记录。

2． CQ的研究
故障的研究，要显示出研究的方法，研究的内容，以及后续的操作。
故障发生的原因：给出故障可能发生的原因分析。
故障的后果：本故障带来的版本危害性。
故障修订建议：阐明故障处理的着手点考虑，列出详细的意见，并给出最终的结论是继续研究，还是挂起，或者修改，或者转交。
3． CQ的方案
故障原因分析
触发条件：解析故障如何触发的――这个和提交人说的触发条件可能不同。
故障原因：故障发生的具体原因。
规避办法：有无规避的方法。
故障的后果：故障带来的影响。
回溯记录：记录以前就已经发生该问题的故障单号和版本。
方案内容
修改内容：修订的具体方法；
波及的版本：本故障影响的版本。
影响的模块：是不是影响其他项目或者开发者的相关模块。
版本兼容和升级的影响。
验证方法：描述故障从哪些功能点或者操作去验证。目的是部分故障单，开发处理含糊，导致测试部无法有效验证。
修改清单
列出修改的代码和文档清单。如果需要修订文档，务必列出修订的文档内容。
4． CQ的审批
根据cq的方案，审核合入的版本。请慎重做好把关作用，免得遗漏。
5． CQ的合入
CQ的合入，严禁走空流程。只有一种例外：就是因为其他项目纠缠的问题，导致实际上我们并没有需要合入代码的时候，才允许走空流程。
严禁合入本CQ单非相关的代码。
在checkout前，要求首先要对需入库的文件，执行update操作；checkout时，要求填写本次修改使用的变更单号，和责任人姓名；
入库完毕，需要再次对相关目录进行Find Checkout操作；
在Find Checkout时，请选择include all ...和 search all ...，在确认无checkout 文件后，再次对相关目录执行update操作，检查是否有hijacked文件，特别是在目录中增加新文件时，若在Add to Source Control操作后，或者直接将新文件copy到目录中后，前面的步骤都很难发现其实未进行checkout 和checkin操作，即其实文件未能入库。
合入的代码，需要经过验证。版本提交前1天，需要进行版本的预编译――科室整体需要安排预编译。