我们如何实施 SonarQube 并实现其巨大潜力

我们如何实施 SonarQube 并实现其巨大潜力

我们希望分享我们在国家结算存管机构开发 DPO 系统(阿拉米达存托和清算会计系统的补充)的现有流程中实施持续分析和衡量 SonarQube 代码质量的平台的经验。

国家结算存管机构(莫斯科交易所集团公司)是主要的金融基础设施公司之一,存储和记录俄罗斯和外国发行人价值超过 50 万亿卢布的证券。 系统执行的操作量不断增长,功能不断增加,需要保持系统源代码的高质量。 实现这一目标的工具之一是 SonarQube 静态分析器。 在本文中,我们描述了将SonarQube静态分析器无缝实施到我们部门现有开发流程中的成功经验。

简单介绍一下部门

我们的能力包括以下模块:向 NSD 客户付款、电子文档管理 (EDF)、交易存储库消息处理(场外交易注册)、客户与 NSD 之间的电子交互渠道等等。 一般来说,大部分工作都是在运营的技术方面。 我们以应用程序为基础开展工作。 出纳员的申请由分析师处理:他们收集客户需求并向我们展示他们对如何融入该计划的愿景。 此外,标准方案是:代码开发-测试-试运行-将代码交付到生产电路给直接客户。

为什么选择 SonarQube?

这是我们部门第一次实现代码质量控制平台——之前我们都是手工做的,只是代码审查。 但不断增长的工作量需要该过程的自动化。 此外,团队中还存在经验不足的员工,对内部开发规定不完全熟悉,容易犯更多错误。 为了控制代码的质量,决定实现静态分析器。 由于SonarQube已经在一些NSD系统中使用,所以没花太长时间就选择了。 此前,其他部门的同事用它分析了Alameda系统(NSD自己的存管和清算会计系统)、CFT(会计、余额、强制和内部报告准备的信息系统)、其他一些系统中的微服务代码。系统。 为了进行实验,我们决定从 SonarQube 的免费版本开始。 那么让我们继续我们的案例。

实施过程

我们有:

  • TeamCity中系统的自动组装;
  • 在GitLab中设置通过MergeRequest从feature分支上传代码到master分支的流程(根据GitHub Flow开发流程);
  • SonarQube 配置为按计划分析 DPO 系统的代码。

我们的目标:在AVE的CI/CD流程中实现自动代码分析。

需要定制:通过静态分析器自动检查代码的过程,每个 MergeRequest 都会发送到主分支。

那些。 目标图片如下:开发人员将更改上传到功能分支后,就会开始自动检查代码中的新错误。 如果没有错误,则允许接受更改,否则必须更正错误。 在初始阶段,我们就能够识别代码中一定数量的错误。 该系统具有非常灵活的设置:它可以配置为适合开发人员的特定任务、每种系统和编程风格。

在 SonarQube 中配置 QualityGate

QualityGate 分析是我们在互联网内部阅读的内容。 最初,我们使用了不同的方法,更复杂,并且在某些方面并不完全正确。 首先,我们通过 SonarQube 运行扫描两次:扫描特征分支和要合并特征分支的分支,然后比较错误数量。 该方法不稳定并且并不总是给出正确的结果。 然后我们了解到,您可以设置错误数量限制 (QualityGate) 并仅分析您上传和比较的分支,而不是运行 SonarQube 两次。

我们如何实施 SonarQube 并实现其巨大潜力

目前,我们仍然使用相当原始的代码检查。 需要注意的是,SonarQube 与某些编程语言不兼容,包括 Delphi。 目前,对于我们的系统,我们仅分析 PLSql 代码。

它的工作原理如下:

  • 我们仅分析项目的 PL/SQL 代码。
  • 在 SonarQube 中配置 QualityGate,以便错误数量不会随着提交而增加。
  • 第一次运行的错误数为229。如果提交期间有更多错误,则不允许合并。
  • 此外,在纠正错误的情况下,可以重新配置 QualityGate。
  • 您还可以添加新的分析项目,例如测试的代码覆盖率等。

工作方案:

我们如何实施 SonarQube 并实现其巨大潜力

在脚本的注释中,可以看到feature分支的错误数量并没有增加。 所以一切都好。

我们如何实施 SonarQube 并实现其巨大潜力

合并按钮变得可用。

我们如何实施 SonarQube 并实现其巨大潜力

在脚本的注释中,您可以看到功能分支中的错误数量已超过允许的数量。 所以一切都很糟糕。

我们如何实施 SonarQube 并实现其巨大潜力

合并按钮为红色。 目前,不禁止上传对错误代码的更改,但这由负责的开发人员自行决定。 将来,您可以防止对主分支进行此类提交。

我们如何实施 SonarQube 并实现其巨大潜力

自我处理错误

接下来,您需要检查系统检测到的所有错误,因为 SonarQube 是根据其严格的标准进行分析的。 他认为的错误实际上可能并不存在于我们的代码中。 因此,您需要检查并记下这是否真的是一个错误,或者在我们的条件下是否不需要编辑。 因此,我们减少了错误的数量。 随着时间的推移,系统将学会理解这些细微差别。

我们到了什么地步

我们的目标是了解在我们的案例中将代码验证转移到自动化是否有利。 而结果也达到了预期。 SonarQube 允许我们使用我们需要的语言,进行相当有效的分析,并且有可能从开发人员技巧中学习。 总的来说,我们对 SonarQube 的第一次体验感到满意,并计划朝这个方向进一步发展。 我们期望未来我们能够在代码审查上节省更多的时间和精力,并通过消除人为因素使其变得更好。 也许在这个过程中我们会发现这个平台的缺点,或者相反,我们会再次确信这是一个很酷、潜力巨大的东西。

在这篇概述文章中,我们讨论了我们对 SonarQube 静态分析器的认识。 如果您有疑问,请写在评论中。 如果您对此主题感兴趣,在新出版物中,我们将更详细地描述如何正确设置所有内容并编写代码来执行此类检查。

正文作者: 阿塔尼亚

来源: habr.com

添加评论