【软件测试】Gitlab+Jenkins+SonarQube计算增量覆盖率
当要求质量内建、测试左移、持续集成、DevOps，代码的增量覆盖率几乎是必定会被提出来的话题。这个方案明确了"谁的代码谁负责"的原则，和当年“小岗村包产到户”一样，开发人员只需要为自己的提交/合并请求来提供代码覆盖率数据，而不再需要为整个团队的代码库和历史旧账掉头发了。团队负责人也乐于实施这样的“最佳实践”，树立一个带电的“质量门禁”，没有达标的，一律拒绝签入或者合并。
但是一直以来，关于增量覆盖率的计算一直是一个讳莫如深的技术。谈起这个话题，大厂的同学们会悠悠的说一句，我们是自研的工具。而关于这几个工具的集成，网络上有无数篇教程。但几乎所有的教程，无论声称的是做PR/MR触发的流水线，还是做Jacoco覆盖率，都只是介绍了如何将这几个工具进行集成，也就是文章的终点停在了SonarQube上能产生覆盖率报告甚至只是Jenkins能触发构建上。
本文将介绍如何使用上述工具实现完整的MR/Push闭环，并真正实现增量覆盖率的计算。
首先假设您已经能够掌握GitLab+Jenkins+Jacoco+SonarQube的流水线的搭建，能够实现MR/Push触发Jenkins构建和Sonar扫描。
也就是以下的一个过程，
1）Gitlab通过push event或者merge request event来触发webhook （webhook url指向某个Jenkins任务，也涉及到token配置）
2) 该webhook将调用Jenkins 的指定流水线任务，可以是传统的freeStyle或者是pipeline的，也可能是团队自研的DevOps 平台的。
3）流水线任务触发 单元测试、集成测试等预先定义好的测试，并生成覆盖率测试报告（maven/gradle +jacoco)
很多自研的方案其实是在这个阶段通过git diff+jacoco报告解析来实现增量分析
4）流水线任务触发Sonar Scanner扫描，并由scanner将扫描结果发送给SonarQube进行分析并产生报告
以上是参考网络上大部分教程可以实现的内容。在实际的项目中，可能还需要以下的过程
5） Jenkins获取SonarQube扫描结果,如覆盖率等指标未达到“质量门禁”的要求，则Jenkins流水线任务失败。
6）Gitlab获取到上述结果，并根据结果接受或者拒绝 push。如果是merge request，则标注本次扫描的结果，供合并评审人员参考，当然这样的merege request一般会被评审人员拒绝。
至此，一个完整的由代码提交所触发的工作流程闭环就形成了，如下图所示
如本文开篇所说，一般介绍三者集成的文章到第三步就结束了，也就是Gitlab 能通过webhook触发Jenkins构建任务，并且能在sonarqube上查看到扫描结果。而一个完整的MR/Push触发CI的流程应该要将上述结果回馈到Gitlab当中。这当中就需要完成4和5的步骤了。
SonarQube Webhook
通过给SonarQube上的某个项目指定WebHook, 就能在该项目被触发并完成扫描结果分析后，调用该Webhook来实现将结果推送给消费者，如Jenkins。
具体的介绍可以参见SonarQube提供的官方说明
https://docs.sonarqube.org/latest/project-administration/webhooks/
以下是该Webhook的内容案例，
以上案例中，SonarQube将上述内容post给指定的url。其中使用了一个最为简单的质量门禁，增量代码覆盖率80%。
通过给SonarQube上的某个项目指定WebHook, 就能在该项目被触发并完成扫描结果分析后，调用该Webhook来实现将结果推送给消费者，如Jenkins。
也就是说，在Jenkins Pipeline中，我们会使用类似这样的脚本来发起扫描并等待SonarQube发回质量门禁的结果
而上述SonarQube Webhook就是用来通知 waitForQualityGate的质量门禁的结果的。
从日志上看，在完成Sonar Scanner扫描并向SonarQube发送结果后，首先会进入短暂的In-Progress状态，
然后是Pending，也就是等待SonarQube完成扫描结果并通过Webhook返回结果。
Jenkins在收到结果后，就可以根据质量门禁的结果进行下一步操作了，如不达标就让整个Jenkins job失败，并最终让MR被拒收。
Gitlab Plugin addGitlabComment &updateCommitStatus
https://docs.gitlab.com/12.10/ee/integration/jenkins.html#configure-a-jenkins-project
https://www.jenkins.io/doc/pipeline/steps/sonar/
前一小段有说到，SonarQube通过Webhook通知Jenkins本次扫描的质量门禁度量结果后，就需要由Jenkins来通知Gitlab了。这里，也是使用了Gitlab Plugin中的功能。如以下是通知Gitlab构建成功的通知
增量代码覆盖率
在聊完了整个工作流程和数据流转之后，终于可以来到本文的重点，也就是如何获得增量的代码覆盖率了。一般来说可以有两个方案
1）在Jenkins构建任务中通过自研工具或者例如diff_cover等开源工具来计算增量的代码覆盖率。
这个方案的核心还是jacoco生成的代码覆盖率报告以及git diff获取到的差量代码这两份报告的解析和计算。
如果采取该方案，则后续的SonarQube扫描部分就可以是可选动作了。
2） 通过SonarQube来计算增量代码覆盖率
这个方案的优势是不需要额外的开发工作或者引入别的工具，并且覆盖率结果连同代码静态扫描结果等能共同形成质量门禁，依托代码覆盖率、测试用例、违规等来综合判断MR或者Push是否满足合并要求。
增量代码覆盖率-SonarQube
首先，SonarQube支持基于增量代码(new code)的质量门禁。以下是官方提供的一个报告，
https://www.sonarqube.org/sonarqube-7-7/
我们可以看到SonarQube提供了增量代码的覆盖率、重复率、缺陷、安全漏洞等等的度量，并可以基于上述数据来综合判断是否通过质量门禁。案例中，由于设立了增量代码85%的覆盖率，而实际值为72.2%，因此质量门禁未通过。
有了解SonaqQube的读者可能要说了，这个方案存在问题。一般我们会在master分支或者是develop分支上计算（增量）代码覆盖率。当我们把待评审的MR/Push代码的扫描结果直接推送到这些分支上的话，如果这个请求经过评审后被拒绝，那这些分支上的数据不是被污染了么？
因此，直接利用master分支是有问题的。这里，我们需要额外利用一个 SonarQube Branch的插件。具体方案是，将待评审的MR/Push的扫描结果推送到一个约定的分支上，如"mr-xxxx"上，这个分支作为一个短分支（short branch),将基于指定的长分支（long branch)进行计算，得到上图的质量门禁计算结果。当然这里的前提是，长分支上的数据和MR/Push的目标分支是实时对应的，否则会引起计算结果的偏差。
具体来说，就是在sonar扫描时指定分支和基线分支，以maven项目为例
mvn clean test sonar:sonar -Dmaven.test.failure.ignore -Dsonar.branch.name=mr-xxx -Dsonar.branch.target=develop
也就是以develop分支为基线，来计算mr-xxx分支相对于develop的代码增量覆盖率，以及静态代码扫描结果，并计算质量门禁结果。
由于SonarQube在社区版上并不提供多分支扫描的功能，因此只有采购develop以上的版本才能具备次功能，或者是在github上使用开源社区提供的sonarqube-community-branch-plugin
总结一下
上述方案中，额外利用了
1）SonarQube Webhook
2) SonarQube 分支插件 和长短分支概念
就能在一般三者集成的方案中实现增量代码覆盖率和质量门禁
以上是 【软件测试】Gitlab+Jenkins+SonarQube计算增量覆盖率 的全部内容， 来源链接： utcz.com/a/131073.html
