SonarSource连续检查的10原则:

开发过程中的所有利益干系人 (不仅仅是开发人员或经理) 必须具有现成的访问权限到有关软件质量的有意义的数据。

管理软件质量必须是每个人的关注从开始的发展, 但是开发团队的终ji责任。

软件质量必须是开发过程的一部分, 这意味着满足质量标准是一个的硬要求能够声明开发完成。

软件质量要求必须是客观的, 不需要主观的通过/失败的决定。软件质量要求必须尽可能多地与所有软件产品共同, 无论他们的细节。

软件质量数据必须是***xin的, 即对代码的***近版本进行测量。

软件产品必须不断检查, 以便在容易发现错误时迅速正确.开发人员必须能够发现新的质量缺陷, 一旦他们被引入, 即在IDE 编写代码时, 类似于拼写检查程序突出拼写错误的方式。

无论是通过推还是拉, 在注入新的质量缺陷时, 都必须提醒利益干系人, 无论这是通过发送电子邮件, 打破了构建或其他方法。

必须跟踪新问题的注入,使团队能够快速、明智地决定质量。

软件质量数据必须同时提供绝dui (在所有代码) 和差异 (新的代码)值, 以便开发团队可以完全控制问题的传入流程。

所有新问题和现有关键问题都必须为解决方案指ding明确的路径和时间线。

持续的检验范式是非常有效的, 并已被证明在现实世界中工作从离岸软件工厂到财富100强企业不等。这些公司成功地使用了连续检测模型来管理项目的内部软件质量所有大小。

一个财富100强的公司与超过2万的开发商使用它管理超过6亿行代码, 在每天分析超过5000应用程序的环境中。

在所有情况下, 连续检查帮助这些公司大大提高了软件质量和稳定, 通常节省数百万美元, 否则将花费在根本原因分析和危机管理。

SonarSource

实现和好处的典型大小

大型国际组织可以对1万多个项目进行分析, 并

分析650–700万行代码在14种语言与8000访问一天在网站上。

IDC 的一位客户正在跟踪1200项目, 其中有1.6亿行代码

通过 SonarQube 扫描, 再加上另外的300项目, 还有1.6亿行代码

被扫描。

另一位客户从二十几个项目到现在已注册的2230多个项目

用户有更多的匿名浏览仪表板。

为什么 SonarQube？

SonarQube 引用 IDC 的讲话需要一种测量和强制软件的方法

和代码质量指标。一个关键的目标是对代码质量进行量化测量, 并

分析这些指标来制定一套基准测量-主要是利用

鼓励良好做法的平台 (并劝阻坏的行为)。

在评估有竞争力的产品时, 他们寻找的是: 品质特征

分析提供 (如死代码分析、影响分析、跨平台分析);

支持的语言 (SonarSource 支持 20 +);代码评审的灵活性;和仪表板

产品和报告分析。服务组织还评估了基于

商业限制和参与限制。

SonarQube 的优点通常包括其整体易用性, 需要更少的时间来学习

并采取。与 SonarQube 的包装选项也有利于***终用户和

服务提供商-"不附加任何字符串" 的企业许可证是对具有动态分发需求和服务提供者的***终用户的帮助, 提供了能够利用的自由

SonarQube 灵活地作为订婚的一部分。

SonarQube 仍在发展其对影响分析的支持, 但同时一些客户

引用已创建解决此问题的变通方法。

使用 SonarQube 的好处

SonarQube 客户描述的功能在解决其

***问题包括以下几个方面:

?代码和质量的能见度, 可以看到热点是在应用程序中

主动包括应用程序质量 "前端" 作为开发的初始和迭代部分

过程仪表板, 用户可以选择处境和

自定义报告。

?的能力, 以不同的层次整合的指标, 在各不相同的意见-在客户

级别, 在开发人员级别和/或业务单位级别-并将它们上卷成 "一个

真理之源 ";一个单一的门户/单点, 每个人都可以去看看他们

需要知道。

?经理/董事可以自定义和使用 SonarQube 来衡量

各个组-服务提供商可以为每个客户自定义仪表板

组织, 他们正在努力解决不同种类的需求和标准。

它们还可以增强现有规则并集成结果, 因为 SonarQube 给出了

这一水平的灵活性。同时, 组织必须注意不要使用

SonarQube 作为 "棍棒" 迫使 "好行为"-成功的公司有

利用信息鼓励更好的做法, 而不是建立 "墙

羞辱 "惩罚个人不良的编码行为。这意味着使用 SonarQube 作为

"诊断指标" 而不是 "基于结果的" 指标, 可以更好的推动成功。

?总的来说, 这些能力使客户能够管理和减轻技术债务

通过一个 cost-effective 的解决方案, 可以扩展到企业级, 并广泛

分布式.SonarQube 帮助组织对代码质量进行基准测试并了解

他们的组织是如何做, 以及他们如何能够和有改进的时间通过

定性和定量的信息。

SonarSource简介

具有 Artifactory 和 Sonarqube 集成的连续交付准备 Gradle 项目当玩弄持续集成/交付/部署的概念时, 我在 Gradle 构建以及如何将它们集成到这些概念中而苦苦挣扎。Gradle 在构建工具环境中越来越重要, 因此我创建了一个关于如何使用它的模板或原型。它将支持所有的内置SonarSource插件,但没有第三方的。我选择了一个场景, 我看到了 Maven 和其他工具已经实现了:

推动风投转向中央风投将更改标记为特定 id 并将其推回中央 VCS使用单元测试执行生成执行声纳分析执行 artifactory 上载此链使您能够不断地将每个更改设置标记、单元测试、分析并上载到您的工件存储库, 以备部署。简而言之, 这是 (从我的角度来看) 持续交货的精神。声纳覆盖7段代码质量体系结构和设计单元测试重复代码潜在bug复杂代码编码标准评论SonarQube接收文件作为输入,并分析他们连同障碍。

环境:

Gradle 3.5 (通过项目的 Gradle 包装)Artifactory: 5.2. 1-OSS, 运行在 http://localhost:8081/artifactorySonarqube: 6.3.1, 跑在 http://localhost:9000注意: 在这种情况下, Sonarqube 和 Artifactory 将由管理员用户使用。产品如这可以帮助组织通过单个集线器来检查和理解软件开发,以开始将软件开发作为一个业务来管理。在实际生产环境中, 必须将其更改为更安全的方式

首先, 我在 Artifactory 中添加了一个本地 (m2-compatible) 和两个远程存储库:

"库-释放-本地" 是为了保存我自己的工件 (这就是为什么它被称为 "本地")"插件-gradle-org" 指向远程回购 "http://plugins.gradle.org/m2/" (这是 gradle 插件所必需的)"repo1-maven-org" 指向远程回购 "http://repo1.maven.org/maven2/" (这是项目的所有其他依赖项所必需的)此外, 我创建了一个虚拟的回购 "释放" 包含所有 3 mentionend 回购。这使得从一个位置获取所有发布的库更容易。通过供应商支持和服务降低风险:为使客户能够从其投资中获得***da价值,SonarQube提供了额外的价值和***支持。

该项目本身并不真正重要的这篇文章。我认为这是一个标准的 java 项目, 遵循 Maven/Gradle 的惯例。更有趣的部分是 Gradle 文件:

gradle/包装/gradle 包装。生成. gradle凭据. 属性gradle. 属性设置. gradle

SonarSource设置

在引擎盖下，这个SonarQube实例依赖于如下所示的许多默认或定制配置设置。

（以上是示例应用程序的截图）

可以通过该界面访问和更改各个组件的配置设置。

更新中心

到目前为止看到的各种仪表板中的许多小部件可以从下面的页面启用或禁用。还可以对所有小部件进行更新和升级，包括SonarQube本身的更新和升级。

升级过程

查看[10]中的升级过程，另见[11]，了解过程之前和之后应该做什么。

通常停止并重新启动SonarQube是在应用更新或升级到一个或多个组件或SonarQube本身之前和之后执行的常见步骤。

结论

在评估这些功能后，它清楚地表明，该产品具有优于其他解决方案的优势，即大量免费插件，基于插件的仪表板系统，除了作为开源项目，还有一个很好的开始用。话虽如此，可能有商业产品有更好的质量评估命题，但不一定有用，除非你是一个大型组织。

使用SonarQube作为创建短反馈循环的工具，并在评估建议的更改的原理后，对代码库进行改进。如果反馈不正确或是假阳性或假阴性 - 一个选项是调整相关组件背后的配置设置，以查看在当前情况下提出的问题是否适用 - 基本上是转动支票或不采取反馈字面上。这是幸运的SonarSource的一个高优先级,虽然它不会被宣布时,它将船舶。