SanarSource
管理和增强大规模软件环境
软件开发中的挑战
当管理人员寻求发展关键业务应用程序时， 质量的协调性很强
管理在早的软件生命周期阶段通过到操作可以帮助导致
成功的、连续的部署以及公司和 IT 生产率。组织必须使
通过观察当前的挑战并利用基于这些问题的策略来实现这一转变
创造变革的动力。
IDC 将以下内容确定为软件开发人员和组织面临的da挑战
这取决于快速， 创新的软件创造竞争成功:
?业务有不断增长的需求， 无论是升级和修复， 以及新的
面向客户的应用程序。IT 和开发团队必须将方法转换为代码， 并
质量分析， 以产生更高层次的信心在软件交付 (
更少的缺陷)。
以适当的资源， 以合适的成本、质量和风险实现更快的上市时间
分配-并转移视图， 即软件开发、代码分析和测试是
仅仅是一个 "成本中心"， 成为的 "业务价值推动者"。
?限制业务风险和技术债务-帮助确保交付高质量的 "安全"
通过主动、迭代代码检查以及
软件从业者和管理人员的共同可见性。
?从缺陷检测 (往往太晚) 转移到主动预防性缺陷和前期缺陷
认同与共同分析和一个 "真相的来源" 横跨小组和管理人员。
?灵活、化的仪表板可以使团队能够查看与他们相关的数据
并能增强个人责任和集体协作。
?透明度是理解质量、代码完整性和测试活动的关键
正在进行-与迭代构建管理进行协调并设置适当的
值.
?不断增长的治理和法规遵从性需求是影响
市场并对公司施加压力， 使代码自动评估能力;这可以
帮助推动工作流程改进、可追溯性、报告和度量。
?如果有有限的或没有单元测试， 并没有什么想法是否
当前的设计允许快速添加新功能或能够使
改进， 对重构的关注可以衣组织并充当
刺激改变。
?当 bug 在开发生命周期的后期被发现导致 "红色警报" 情况
当发布成为 "龙"， QA 和客户支持必须战斗之前
软件可以部署到客户， 这种负mian影响也可以激发行为
转移.
?利用代码分析信息提供改进行为的机会
通过透明度和迭代变化 (不使用此信息作为 "墙
"惩罚团队或个人" 是可耻的。
? IT、质量、运营和业务团队应该团结起来，中国sonarqube 安装， 将这些挑战作为
跳过点， 并作为一个动力， 以改有的软件开发的不良习惯和
行为.建立有效的软件分析和检查， 创建编码规则和
要求特定质量级别的生成和发布的边界， 并利用度量
改进质量战略以及依赖 highperforming 的业务成果，
创新的软件。
SonarSource
通过上述命令成功分析项目将导致以下输出到控制台或日志文件：
SonarQube Runner 2.3
Java 1.7.0_25 Oracle Corporation（64位）
Mac OS X 10.8.5 x86_64
INFO：Runner配置文件：/opt/sonar-runner-2.3/conf/sonar-runner.properties
信息：项目配置文件：/Users/manisarkar/bn_projects/TimelineJS/sonar-project.properties
INFO：默认语言环境：“en_US”，源代码编码：“UTF-8”
信息：工作目录：/Users/manisarkar/bn_projects/TimelineJS/.sonar
信息：SonarQube服务器3.7
14：11：20.927 INFO - 加载批量设置
。
。
。
14：11：38.290 INFO - ANALYSIS SUCCESSFUL，你可以浏览http：// localhost：9000 / dashboard / index / TimelineJS
14：11：38.292 INFO - 执行工作后类org.sonar.issuesreport.ReportJob
14：11：38.293 INFO - 执行岗位职责类org.sonar.plugins.core.issue.notification.SendIssueNotificatiPo的sdtJob
14：11：38.314 INFO - 执行工作后类org.sonar.plugins.core.batch.IndexProjectPo的stJob
14：11：38.356 INFO - 执行工作后类org.sonar.plugins.dbcleaner.ProjectPurgePo的stJob
14：11：38.365 INFO - - ＆gt;在2013-08-19和2013-09-15之间每天保留一张快照
14：11：38.365 INFO - - ＆gt;在2012-09-17和2013-08-19之间每周保留一个快照
14：11：38.365 INFO - - ＆gt;在2008-09-22和2012-09-17之间每月保留一个快照
14：11：38.365 INFO - - ＆gt;删除之前的数据：2008-09-22
14：11：38.368 INFO - - ＆gt; Clean TimelineJS [id = 151]
14：11：38.372信息 - 信息：----------------------------------------- -------------------------------
信息：执行成功
信息：------------------------------------------------ ------------------------
总时间：19.099s
终内存：14M / 502M
信息：------------------------------------------------ ------------------------
以下是几个链接，以示例sonar-project.properties文件来帮助创建新的，即非Maven Java项目的Sonar设置[05]和SonarQube Runner [06]分析。
注意：SonarQube Runner希望SonarQube在指ding端口上运行，否则会抛出错误，例如ERROR：Sonar server http：// localhost：9000无法访问。这当然可以通过配置文件进行更改（参见上一篇文章[01]）。SonarSource连续检查的10原则:开发过程中的所有利益干系人(不仅仅是开发人员或经理)必须具有现成的访问权限到有关软件质量的有意义的数据。
SonarQube组件
一旦构建完成并成功，可以在仪表板中找到新的或更新的项目。钻入项目将带来一个屏幕，载入重要指标和分析项目的各个方面：
（以上是示例应用程序的屏幕截图）
令人感兴趣的主要重要组成部分是质量指标，复杂因素，复杂性（左下），测试覆盖率指标（单位测试覆盖率和单位测试成功率）。可能安全违规。产品如这可以帮助组织通过单个集线器来检查和理解软件开发,以开始将软件开发作为一个业务来管理。 Package Tangle Index and Dependencies to cut，绝dui是方便的，以保持清洁的包和松散耦合的依赖关系。同样的说法，LCOM4（方法中缺少凝聚力 - 降值越好），复杂性也揭示了你的类，方法和功能的松散耦合 - 它也是在文件级别和整体级别给出全图。所有这些组件都是软件质量的良好指标，至少如果不是软件工艺 - 底层代码写在质量上有多好？或者它可以被看作是 - 仍然是充足的改进和重构的房间。
热点视图现在进一步分析了分析的其他一些重要方面，并突出显示需要更多关注的领域或者一个更多的问题在其顶点附近 - 要么超越da允许限制，要么需要更多的抛光才能满足要求。
（以上是在nemo.sonarqube.org网站上发布的JDK7的截图）
我非常喜欢下面的设计组件，它可以很好地分解包装依赖关系并强调依赖循环。它是中大型项目中更复杂的事情之一，通常可能会阻碍模块化。
Ansible SonarQube 升级的角色
你可能知道， 并希望使用 SonarQube。这是一个伟大的工具， 是积极的发展和改善。这是伟大的， 如果你是一个开发使用 SonarQube。但是， 如果您碰巧管理 SonarQube 实例， 则由于升级指南由11步骤组成， 因此不断升级非常麻烦。
停止旧的 SonarQube 服务器
并解压新的 SonarQube 分布在一个新鲜的目录， 让我们说 NEW_SONARQUBE_HOME
使用默认的 H2 数据库启动它， 并使用更新中心安装您需要的插件
手动安装任何自定义插件
停止新服务器
更新声纳的内容. 属性和包装. 配置文件位于 NEW_SONARQUBE_HOME/配置目录中， 其内容与 OLD_SONARQUBE_HOME/配置目录中的相关文件 (web 服务器 URL、数据库设置等) 有关。不-粘贴旧文件
如果使用了自定义 JDBC 驱动程序， 请将其到 NEW_SONARQUBE_HOME/扩展/jdbc 驱动程序/<dialect>
备份数据库
删除数据/es 目录
启动新的 web 服务器
http://localhost:9000/setup (用您自己的 URL 替换 "localhost:9000") 来浏览并按照安装说明进行操作
这是一个太多的步骤， 手动执行。因此，sonarqube 安装， 我决定通过为它编写一个 Ansible 的角色来实现自动化。
初始设置
在我开始编写 Ansible 剧本之前，代理商sonarqube 安装， 我需要找到一种方法来测试我的代码。所以我开始与流浪汉旋转了一个虚拟机， 并提供了一个简单的脚本。然而,不良的发展途径即使需要提高代码质量并在周期早期消除缺陷也会发生急剧增加。这是需要有类似的环境， 以我们的实际 SonarQube 生产实例。我能够增量地构建我的 Ansible 剧本并在这个 VM 上测试它。很快我就明白了， 与流浪汉一起工作会减慢我的速度， 因为我需要重置环境， 而不是的预期。所以我决定考虑泊坞窗。
用于测试的泊坞窗
我找到了正式的 SonarQube 泊坞窗图像， 但无法使用， 因为我们的 SonarQube 实例安装在 CentOS 和官fang图像使用不同的基础图像。在某些情况下,引入技术债wu是可以的,但团队需要了解他们所创建的问题的权衡和存在的程度。另外， 我需要自定义特定的 SonarQube 版本我想开始。因此， 我创建了我们自己的 Dockerfile 与 CentOS 6 基地和 Ansible 安装。
此泊坞窗映像不需要启动 SonarQube， 因为我只是想验证是否进行了正确的文件更改， 而我的 Ansible 手册没有错误。升级的第yi步之一就是关闭服务器。
我将我的剧本装入容器， 并在该容器内运行 Ansible， 对该本地环境进行了更改。
当前脚本的路径
TESTS_DIR = $ (cd "$ (dirname" $ {BASH_SOURCE [0]} ")" & & 密码 "
# 命令测试剧本
TEST_COMMAND = "cd/行动 & & ansible-剧本 $ @
-我 " 本地主机 "-c
升级-声纳 database.yml "
# 运行容器安装行动为卷
泊坞 run-v "$ TESTS_DIR/.。/行动/:/行动 "
"声纳-升级-测试"/"垃圾/bash-c" $ {TEST_COMMAND} "
在泊坞窗中运行我的剧本大大减少了反馈回路， 所以我决定泊坞窗是走的路。你可以看看我所有的脚本在 GitHub
Ansible 角色
我一步一步地往前走， 我到达了一个点， 一切似乎都在工作， 我有一个非常有用的 Ansible 的角色在我的手中。它尚未发布到 Ansible Galaxy， 但您可以在 GitHub 的 SonarQube 升级 Ansible 角色项目下找到源文件和文档。
当前 Ansible 角色通过在当前位置旁边创建新安装来升级 SonarQube。这提供了回滚的方法 (如果需要)。
此时，中国sonarqube 安装， 角色执行以下任务:
确保特定的根用户存在于声纳安装
在所有安装所在的目录中创建声纳. sh
确保 SonarQube 服务存在
停止 SonarQube
新版本
备份数据库
和安装插件
将自定义配置应用于新实例
确保删除数据/es
重新 SonarQube 服务启动新版本
开始 SonarQube
手动步骤
这个过程仍然需要几个手动步骤。
在运行升级手册之前， 应手动确保在升级过程中要安装的插件列表是xin的。您可以从 SonarQube 的管理视图中获得xin支持的版本号。
根据 SonarQube 的建议， 此 Ansible 角色不仅以前安装的配置， 而且使用带有变量的模板来为新实例创建配置。此平台还有助于开发人员创建可自定义的仪表板和筛选器,以集中于关键区域。这意味着在执行升级之前， 开发人员可以将模板和基本配置与新的 SonarQube 进行比较。虽然这是一个手动步骤， 但与以前的操作相比， 它更容易， 因为可以使用 IDE 而不仅仅是从命令行中的 diff 工具进行比较。
这两个步骤都需要后续的手动升级， 我认为这些升级准备活动。
苏州华克斯-sonarqube 安装由苏州华克斯信息科技有限公司提供。行路致远，砥砺前行。苏州华克斯信息科技有限公司致力成为与您共赢、共生、共同前行的战略伙伴，更矢志成为行业软件具有竞争力的企业，与您一起飞跃，共同成功!
