sonarqube本地代码

越来越多的组织正在实施 ，以便在通过中间开发和测试环境后，更快地将质量代码导入生产环境。 尽管诸如版本控制，持续集成和部署以及自动化测试之类的事情都属于DevOps的范畴，但仍然存在一个关键问题：组织如何才能量化代码质量 ，而不仅仅是量化部署速度？

是填补这一空白的一种选择。 它是一个开放源代码平台，可通过对源代码进行自动静态分析来持续检查代码质量。 SonarQube可以分析20多种编码语言，并在各种项目类型中存储问题。

SonarQube还提供了一个集中的位置，用于同时维护和管理多个多语言项目中的代码问题。 可以为每个项目实施自定义规则。 连续检查允许对代码运行状况的总体轨迹进行分析。

SonarQube还可以集成到持续集成和开发（CI / CD）管道中，从而帮助并自动化确定代码对生产环境的就绪程度的过程。

它可以测量什么

SonarQube开箱即用，可以测量关键指标，包括错误，代码气味，安全漏洞和重复代码。

• 错误是代码中不正确或可能无法正常运行的部分，因此会产生潜在的错误结果。 这些是显而易见的错误，应在代码发布到生产环境之前进行修复。
• 与错误的不同之处在于，检测到的代码可能会正确执行预期的功能。 但是，可能难以维护，导致将来的错误，无法通过单元测试发现或存在其他问题。 为了实现长期可维护性，立即修复代码异味很聪明。 通常在编写代码时很难检测到代码气味，但是SonarQube的静态分析是发现它们的一种方法。
• 安全漏洞的确切含义是：代码中某处的漏洞可能会带来安全问题。 这些漏洞应该得到修复，以防止黑客利用它们。
• 重复的代码听起来也很准确：在源代码中重复的部分代码。 代码重复是软件设计中的不良做法。 总体而言，如果对一部分进行更改而不对另一部分进行更改，则会导致可维护性问题。 例如，识别代码重复可以使将重复的代码打包到一个库中以便重复使用变得更加容易。

存在哪些自定义选项

因为它是开源的，所以SonarQube鼓励用户开发并提供自定义选项。 当前，有60多个可用于增强SonarQube的即用型分析功能。

创建大多数插件是为了增加SonarQube可分析的编码语言的数量。 其他插件可用于分析额外指标或包括所显示仪表板的其他视图。 本质上，如果组织需要检查自定义指标，想要在其自己的仪表板上以特定方式查看其分析数据或使用SonarQube不支持的编码语言，则可能有可用的自定义选项。 如果所需的功能还不存在，则SonarQube源代码的开放性使其可以开发自定义解决方案。

用户还可以自定义应用于每个特定编码语言分析器的规则。 可以通过SonarQube的用户界面为每种语言和每个项目选择和取消选择规则。 这些选项认识到需要特定于项目的规则，以及将所有数据和配置维护在中央位置。

为什么重要

SonarQube为组织提供了一个集中的位置，可以在多个项目中管理和跟踪其代码中的问题。 它还可以结合质量门进行连续检查。 对项目进行分析后，随着软件的修改，进一步的分析将更新原始统计信息，以反映最新的更改。 此跟踪使用户可以查看解决代码问题的方式和速度，并符合“尽早发布并经常发布”的思想。

此外，SonarQube可用于 ，例如在诸如和类的工具上运行的 。 质量门将反映代码的整体健康状况，并且通过与Jenkins之类的工具集成，可以在决定何时将代码发布到生产环境中发挥重要作用。

本着DevOps的精神，SonarQube可以量化代码质量，以帮助组织满足内部需求。 为了加快代码生产和发布的周期，组织必须意识到其技术债务和软件问题。 通过发现这些信息，SonarQube可以帮助组织更Swift地生产可能的最高质量的软件。

想了解更多？

SonarQube已获得GNU通用公共许可证的许可，其源代码可在 。 越来越多的用户对SonarQube，其功能及其功能感兴趣。 和上有活跃的社区； 这些以及对有兴趣使用SonarQube的任何人都非常有帮助。

翻译自:

sonarqube本地代码