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配置)

  1. 该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一般会被评审人员拒绝。

至此,一个完整的由代码提交所触发的工作流程闭环就形成了,如下图所示


r1hendj82u.png

如本文开篇所说,一般介绍三者集成的文章到第三步就结束了,也就是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%,因此质量门禁未通过。


94udy4f7wl.png

有了解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

  1. SonarQube 分支插件 和长短分支概念

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

你可能感兴趣的:(Gitlab+Jenkins+SonarQube计算增量覆盖率(转))