sonarqube教程-苏州华克斯公司

sonarsource连续检查的10原则:

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

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

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

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

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

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

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

必须---新问题的注入，使团队能够快速、明智地决定。

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

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

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

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

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

将sonarqube指标集成到tfs构建中 - 简介

2014年7月31日/ andybdev

我一直在努力将sonarqube整合到我们每周运行的tfs中。如果你不知道sonarqube是否检查出来。它是一个---的方法来集中有关您的代码的信息，这有助于捕获和---关注kpi的人的指标（如果我们必须让他们至少对他们的代码有积极的作用），同时给那些“它是一个中心的地方，sonarqube教程，可以看到他们可以改进的代码等问题。

以前，我们从tfs开发了一个单独的jenkins构建阅读源，但是我们希望摆脱这个额外的构建，并且只需在tfs中执行一次 - 似乎有点浪费和耗时地整理jenkins以及tfs。事实证明，我已经有了---的---（在写作的时候），近才有声纳可以处理微软测试结果和覆盖文件的上传（分别为.trx和.coverage） - http：//docs.codehaus .org /显示/ sonar / c％23 +插件。

方法 - 使用标准的tfs build工具包

不幸的是，将sonarqube集成到tfs构建中并不是直接的过程。那里已经有可以为您进行扫描和上传方面的定制活动（http://www.vlaquest.com/2013/10/sonar-build-activity-for-tfs-updated/）。我不太喜欢自定义程序集，因为您需要创建一个项目来管理模板，并提供大量引用来删除所有的---和错误，并且实际上允许您配置导入的活动，从那时起就成为一个需要从项目中编辑你的模板 - 我知道..它没有什么大不了的，但我宁愿把它作为一个简单的可编辑工作流程。然后，您需要将程序集提供给构建控制器，我希望避免需要这样做 - 加上我曾经遇到过这样的问题，以便与过去的托管team foundation service一起工作，sonarqube教程，这在历史的上使我无法避免。

考虑到这些要点，我已经采取了一种方法，这意味着大多数工作可以使用标准活动在构建模板中完成，其余的工作可以在几个可以坐在源中的批处理文件中完成。

我会引导你完成这个过程。