越来越多的组织正在实施 DevOps，以便在通过中间的开发和测试环境后，更快地将高质量代码投入生产环境。尽管诸如版本控制、持续集成和部署以及自动化测试等都属于 DevOps 的范畴，但仍然存在一个关键问题：组织如何量化代码质量，而不仅仅是部署速度？
SonarQube 是填补这一空白的一个选择。它是一个开源平台，通过自动静态分析源代码，持续检查代码质量。SonarQube 可以分析 20 多种编程语言，并将问题存储在各种项目类型中。
SonarQube 还提供了一个集中位置，用于同时维护和管理多个多语言项目中的代码问题。可以为每个项目实施自定义规则。持续检查允许分析代码健康状况的总体轨迹。
SonarQube 还可以集成到持续集成和开发 (CI/CD) 管道中，协助并自动化确定代码是否准备好用于生产环境的过程。
它可以衡量什么
开箱即用，SonarQube 可以衡量关键指标，包括错误、代码异味、安全漏洞和重复代码。
- 错误是代码中不正确或可能无法正常运行的部分，因此可能会产生错误的结果。这些是明显的错误，应在将代码发布到生产环境之前修复。
- 代码异味与错误不同，因为检测到的代码可能运行正确且符合预期。但是，它可能难以维护，导致未来的错误，无法通过单元测试发现，或存在其他问题。为了长期可维护性，最好立即修复代码异味。编写代码时通常很难检测到代码异味，但 SonarQube 的静态分析是发现它们的一种方法。
- 安全漏洞顾名思义：代码中某处存在的缺陷，可能会带来安全问题。应修复这些漏洞，以防止黑客利用它们。
- 重复代码也顾名思义：源代码中重复的代码部分。代码重复是软件设计中的不良实践。总的来说，如果对一部分进行更改但不对另一部分进行更改，则会导致可维护性问题。识别代码重复可以更轻松地将重复代码打包到库中以供重复使用，例如。
存在哪些自定义选项
由于 SonarQube 是开源的，因此鼓励用户开发和提供自定义选项。目前有 60 多个 插件 可用于增强 SonarQube 的开箱即用分析功能。
大多数插件的创建是为了增加 SonarQube 可以分析的编程语言数量。其他插件可以分析额外的指标或包含用于显示仪表板的其他视图。从本质上讲，如果组织需要检查自定义指标，希望以特定方式在其自己的仪表板上查看其分析的数据，或者使用 SonarQube 不支持的编程语言，则可能存在自定义选项。如果所需的功能尚不存在，SonarQube 源代码的开放性使其可以开发自定义解决方案。
用户还可以自定义应用于每种特定编程语言分析器的规则。可以通过 SonarQube 的用户界面为每种语言和每个项目选择和取消选择规则。这些选项认识到项目特定规则的需要，以及在中心位置维护所有数据和配置的需要。
为什么它很重要
SonarQube 为组织提供了一个集中位置，用于管理和跟踪其多个项目中代码中的问题。它还允许持续检查与质量门禁相结合。一旦项目经过分析，随着软件的修改，进一步的分析会更新原始统计信息，以反映最新的更改。这种跟踪允许用户查看代码问题解决的程度和速度，这与“尽早发布，频繁发布”的心态一致。
此外，SonarQube 可以用于 持续集成管道，例如在 Hudson 和 Jenkins 等工具上运行的管道。质量门禁将反映代码的整体健康状况，并且通过与 Jenkins 等工具集成，可以在决定何时将代码发布到生产环境方面发挥重要作用。
本着 DevOps 的精神，SonarQube 可以量化代码质量，以帮助组织满足内部要求。为了加快代码生产和发布周期，组织必须了解其技术债务和软件问题。通过揭示这些信息，SonarQube 可以帮助组织更快地生产最高质量的软件。
想了解更多？
SonarQube 在 GNU Lesser General Public License 下获得许可，其源代码可在 GitHub 上找到。越来越多的用户对 SonarQube、其功能和能力感兴趣。在 Twitter 和 Google 上有活跃的社区；这些以及 SonarQube 博客 对于任何有兴趣开始使用 SonarQube 的人都有帮助。
2 条评论