质量平台-方案设计
一、背景
1、目前测试团队的测试结构主要是业务测试，发现的问题偏黑盒，无法从代码层面找出问题，比如某种条件下触发的空指针、锁未释放等。
2、随着业务迭代越来越多，代码行数越来越多.可能会引入重复代码、代码复杂度高等问题。
3、codereview阶段更多的关注于业务逻辑的实现，可能会忽视编程规范。
二、目的
1、完善测试结构，对代码的质量做一定程度的保障
2、减轻codereview人员负担，更聚焦在业务逻辑的实现和设计的合理性
3、收集研发人员编程过程中的质量
三、做法
1、引入代码扫描工具，在个人提交和merge request到发布分支阶段实现质量评估
2、对merge request进行强制审核机制，确保未达标的代码不进入提测分支
3、只针对增量问题做检查
四、方案设计
五、SOP
1、git工程对发布分支做push保护，只能通过merge request做提交 ----颖超沟通接入
2、merge request通过前务必检查质量平台是否存在未审核的检查记录，否则部署测试环境阻断
六、关键数据
实现过程中的关键接口
gitlab的webhok调用接口：/sonar/gitCallBack
备注：需要配置token, 在header中 X-Gitlab-Token=123456
push事件回调参数示例：
merge request：
首次提交merge request，对应状态：merge_status : "preparing"
merge request没有被审核通过执行前，提交的请求会自动加入这次merge request，此时产生的merge request event传参中的状态为merge_status : "unchecked"
merge request被审核通过执行后，event传参中的状态为：merge_status : "can_be_merged"
对应动作状态：
| merge创建 | merge未通过之前又来了push | merge通过 | merge关闭 | merge关闭后再次打开 | |
| merge_status : "preparing" | merge_status : "unchecked" | merge_status : "can_be_merged" | merge_status : "can_be_merged" | merge_status : "can_be_merged" | |
| action : "open" | action : "update" | action : "merge" | action : "close" | action : "reopen" | 如果为open,则进行一次检查 如果为merge, 相当于已经审核通过,merge完代码了，此时再次进行一次检查记录数据 如果为close，则放弃执行 |
| state : "opened" | state : "opened" | state : "merged" | state : "closed" | state : "opened" | |
| oldrev : "17bb4e9c2f564e34a32adcfd2971cf49e8a2517e" 会记录上一个提交点commit_id |
sonar的webhok调用接口：/sonar/sonarCallBack
备注：需要在执行检查命令时增加-Dsonar.analysis.token=123456
回调参数示例： qualityGate质量阀 对应的数据 taskId 本次检查的标识 project.key sonar中项目唯一标识 project.name 项目名称
七、扫描规则
简单来说，规则（Rule）表示应该遵循的编码规范或最佳实践，如果代码没有满足（或者破坏）某一规则，就有可能产生问题（Issue），问题分为三类：
- Bugs——可能出现逻辑错误的代码块，例如unused代码，bool表达式为定值
- Vulnerability——安全问题
- Code Smells——可维护性问题。引申出了一个技术债务（Debt）的概念，即修复这些可维护性问题需要的时间。
JAVA 当前规则 （目前629条）
其他语言的规则
为了方便对规则进行定制化，Sonarqube提供了对规则的组合机制——Quality Profile，每一个Profile是针对特定语言的规则集合。系统对每一种语言都提供（或者由扩展的插件提供）内置的Profile：
名为"Sonar Way"的Profile是只读的，可以作为一个自定义规则扩展的起点。一般来说，项目会默认使用语言所对应的”默认“Profile，但通常会针对一类项目（比如lib，service，script）定制不同的Profile，由项目自行选择：
八、度量指标与质量阈
8.1 度量指标
Sonarqube主要从7个维度度量代码质量：
- 可靠性——指标包括：Bug数量、可靠性等级（A-E打分）、修复工作时间
- 安全性——指标包括：Vulnerabilities数量、安全性等级（A-E打分）、修复工作时间
- 可维护性——指标包括：Code Smells数量、技术债务、修复工作时间
- 测试覆盖率——覆盖行数、覆盖率、分支覆盖率等
- 重复——重复行数、重复块、重复文件、重复密度
- 大小——代码行数、注释行数、类数量、文件数量、方法数等等
- 复杂度
- 圈复杂度——基于代码的分支计算出来的复杂度，即圈复杂度。当一个方法的控制流多了一个分支，它的复杂度就会增加1。每个方法的最小复杂度为1。
- 认知复杂度——理解代码的控制流的难易程度。
SonarQube 指标定义
8.2 质量阈（Quality Gates）
有了度量指标，就可以用它们来衡量一个项目是否达到了交付所应该满足的质量条件。Sonarqube的质量阈值定义如下：
一旦出现上述指标条件，Quality Gate就会变成Red（错误状态），表示不满足交付所要求的的质量条件。一个例子如下：
上图所示的项目中：
- 新增代码覆盖率为0，<80%
- 可靠率为C，劣于A
- 安全率为E，劣于A
所以质量阈显示为红色（错误）
九、规则指标
使用sonarqube自带规则