H5W3
当前位置:H5W3 > 其他技术问题 > 正文

【软件测试】Gitlab+Jenkins+SonarQube计算增量覆盖率

【软件测试】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+Jenkins+SonarQube计算增量覆盖率

        如本文开篇所说,一般介绍三者集成的文章到第三步就结束了,也就是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的内容案例,

    【软件测试】Gitlab+Jenkins+SonarQube计算增量覆盖率

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

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

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

【软件测试】Gitlab+Jenkins+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构建成功的通知

【软件测试】Gitlab+Jenkins+SonarQube计算增量覆盖率

增量代码覆盖率

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

        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%,因此质量门禁未通过。

【软件测试】Gitlab+Jenkins+SonarQube计算增量覆盖率

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

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

本文地址:H5W3 » 【软件测试】Gitlab+Jenkins+SonarQube计算增量覆盖率

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址