Sonar介绍
Sonar 是一个用于代码质量管理的开放平台。通过插件机制,Sonar 可以集成不同的测试工具,代码分析工具,以及持续集成工具。与持续集成工具(例如 Hudson/Jenkins 等
)不同,Sonar 并不是简单地把不同的代码检查工具结果(例如 FindBugs,PMD
等)直接显示在 Web 页面上,而是通过不同的插件对这些结果进行再加工处理,通过量化的方式度量代码质量的变化,从而可以方便地对不同规模和种类的工程进行代码质量管理。
在对其他工具的支持方面,Sonar 不仅提供了对 IDE
的支持,可以在 Eclipse
和 IntelliJ IDEA
这些工具里联机查看结果;同时 Sonar 还对大量的持续集成工具提供了接口支持,可以很方便地在持续集成中使用 Sonar。
此外,Sonar 的插件还可以对 Java
以外的其他编程语言提供支持,对国际化以及报告文档化也有良好的支持。
名词解释
详见: https://docs.sonarqube.org/latest/user-guide/rules/
- Code Smell (Maintainability domain)
- Bug (Reliability domain)
- Vulnerability (Security domain)
- Security Hotspot (Security domain)
概念 | 定义 |
快照 | 在给定时间针对给定项目的一组衡量和问题。每次分析都会生成一个快照。 |
衡量 | 给定文件或项目在给定时间的度量值。例如,MyClass上有125行代码覆盖到了,或者project myProject上有30.5%的重复行密度 |
问题 | 当一段代码不符合规则时,快照上会记录一个问题。问题可以记录在源文件或单元测试文件中。有 3 种类型的问题:Bug、代码异味和漏洞 |
Bug | An issue that represents something wrong in the code. If this has not broken yet, it will, and probably at the worst possible moment. This needs to be fixed. Yesterday. |
代码气味 | 代码中与可维护性相关的问题。保持原样意味着维护人员最多会比他们对代码进行更改更难。最坏的情况是,他们会对代码的状态感到困惑,以至于在进行更改时会引入额外的错误。 |
漏洞 | 漏洞是影响应用程序安全性的问题,需要立即修复。 |
安全热点 | 安全热点是一段对安全敏感的代码,它会突出显示,但不一定会影响整个应用程序的安全性。由开发人员检查代码,以确定是否需要修复程序来保护代码。(Code Review时确认是否需要修复) |
新代码 | 从上次检查后的增量代码 |
规则 | 应遵循的编码标准或实践。不遵守编码规则会导致错误、漏洞、安全热点和代码异味。规则可以检查代码文件或单元测试的质量。 |
修复成本 | 修复漏洞和可靠性问题所需的估计时间。 |
技术债务 | 修复所有可维护性问题/代码异味所需的估计时间 |
活动趋势 | 每次快照的历史记录趋势图 |
本地安装Sonar插件
idea安装SonarLint插件, 规则和SonarQube平台上的一样
jetbrains插件地址: https://plugins.jetbrains.com/plugin/7973-sonarlint
官网推荐的系统集成方式
- 开发人员的代码在自己的IDE和使用SonarLint运行局部分析。
- 开发人员推他们的代码到自己喜爱的供应链管理:GIT,SVN…
- 持续集成服务器触发自动构建和SonarQube扫描仪的运行SonarQube分析所需的执行。
- 分析报告被发送到SonarQube服务器进行处理。
- SonarQube服务器处理和存储分析报告导致SonarQube数据库,并显示结果在UI中。
- 开发者审核,评论,挑战他们的管理,并通过SonarQube UI减少他们的技术债务问题。
- 开发经理收到分析报告。 OPS使用API从SonarQube自动化配置和提取数据。 OPS使用JMX来监控SonarQube服务器。
Q&A
- 一个项目分析哪个分支,是不是只能管理员来控制,如果多个开发者在开发多个分支,想各自对不同的分支来分析,该怎么做?
- 现在的提交分析的机制是什么样子的?
- 提交成功后有没有通知机制?
- 单元测试的覆盖率该如何集成到SonarQube上?
- 有没有对于那些对业务无实际坏影响的代码,在sonar中能不能定制化规则,把这些异味或者显示修改的地方去掉