当要求质量内建、测试左移、持续集成、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的内容案例，

 {
         "serverUrl": "http://localhost:9000",    "taskId": "AVh21JS2JepAEhwQ-b3u",    "status": "SUCCESS",    "analysedAt": "2016-11-18T10:46:28+0100",    "revision": "c739069ec7105e01303e8b3065a81141aad9f129",    "project": {
             "key": "myproject",        "name": "My Project",        "url": "https://mycompany.com/sonarqube/dashboard?id=myproject"    },    "properties": {
         },    "qualityGate": {
             "conditions": [            {
                     "errorThreshold": "80",                "metric": "new_coverage",                "onLeakPeriod": true,                "operator": "LESS_THAN",                "status": "NO_VALUE"            }        ],        "name": "SonarQube way",        "status": "OK"    }}

以上案例中，SonarQube将上述内容post给指定的url。其中使用了一个最为简单的质量门禁，增量代码覆盖率80%。

通过给SonarQube上的某个项目指定WebHook, 就能在该项目被触发并完成扫描结果分析后，调用该Webhook来实现将结果推送给消费者，如Jenkins。

也就是说，在Jenkins Pipeline中，我们会使用类似这样的脚本来发起扫描并等待SonarQube发回质量门禁的结果

 stage ("SonarQube analysis") {
        steps {
           withSonarQubeEnv('SonarQube') {
              sh "mvn clean test sonar:sonar"         }      def qualitygate = waitForQualityGate()      if (qualitygate.status != "OK") {
              error "Pipeline aborted due to quality gate coverage failure: ${qualitygate.status}"      }   }}

而上述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构建成功的通知

   stages {        stage('gitlab') {            steps {              echo 'Notify GitLab'               updateGitlabCommitStatus name: 'build', state: 'pending'                  updateGitlabCommitStatus name: 'build', state: 'success'            }   }     }

增量代码覆盖率

在聊完了整个工作流程和数据流转之后，终于可以来到本文的重点，也就是如何获得增量的代码覆盖率了。一般来说可以有两个方案

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 分支插件 和长短分支概念

就能在一般三者集成的方案中实现增量代码覆盖率和质量门禁