金融行业 DevOps 解决方案，第 4 部分 基于 Sonar 的持续集成质量改进

什么是软件度量？为什么要质量度量？

软件度量是一种将软件工程中各种影响软件产品最终质量的因素转化成量化表示以利于客观评价的科学方法。IEEE 在“Standard for Software Quality Metrics Methodology”中对软件度量（Metrics）就给出了定义：度量是一个函数，它的输入是软件数据。输出是单一的数值，能用以解释软件所具有的一个给定属性对软件质量的影响程度，软件质量度量是对影响软件质量的属性进行的定量测量。

在软件开发中软件度量是提高软件质量的重要方法之一，也是软件维护的重要组成部分，度量能为软件产品或者项目提供量化的测量结果，可以避免人为主观论断的差错。对国内的金融企业来说，随着大量用户交互系统的上线以及软件开发节奏的加快，软件产品质量的重要性也越发凸显，度量作为其提高软件质量的重要技术也越来越受到人们的关注。

在 DevOps 交付工具平台中的质量度量需求

在 DevOps 交付工具平台中的代码质量度量需求

实施的整个 DevOps 交付工具平台中，持续集成是其中非常关键的用于保证开发过程产品质量的有效实践，目前已在整个业界得到广泛应用。通常情况下，在持续集成中，不仅会对构建完成的代码进行动态的自动化测试，同时也会通过代码静态分析的方式自动发现代码中所存在的潜在的质量隐患。在静态代码分析中，除了将代码中违反静态规则的潜在漏洞发现出来，更为重要的是需要将这些潜在漏洞反馈给开发团队，使得开发团队能够及时加以改进，从而在不断持续集成的过程中不断演进，改进代码质量。因此，在 DevOps 的交付工具平台中，我们就不仅需要能够在早期尽快发现代码质量隐患的静态分析工具，同时还需要与这个分析工具相匹配的度量体系。在该度量体系中，需要达到如下几个目标：

1. 定义一套比较客观简单的代码质量度量指标；
2. 基于该标准设计简单易懂的度量统计报告，从而方便开发人员使用；
3. 需要结合最新的技术趋势，以更为灵活丰富的手段与开发团队沟通联系。

静态代码分析工具 Sonar 介绍

对于静态代码分析，目前，业界已经存在大量的开源静态代码分析工具，在本文的实施案例中，我们选用了业界普遍使用的 Sonar 作为我们整个 DevOps 交付工具平台中的静态代码分析工具。本文所实施 DevOps 交付流水线的其他工具，如 Rational Build Forge，可以和 Sonar 进行无缝集成，从而实现包括自动化构建，代码分析，自动化测试以及度量的持续集成实践。

Sonar（现改名为 SonarQube）是一个开源的代码质量管理平台，专注于持续分析并度量源代码的质量。Sonar 具有以下特点：

• 支持 20 种以上的程序语言：如 Java，C， C++，C#，PHP，Flex Groovy，JavaScript，Python，PL/SQL 及 COBOL 等；
• 提供重复代码，代码标准，单元测试，代码覆盖，复杂代码，潜在代码，注释以及设计和架构的报表；
• 记录度量历史以及各种不同的度量视图；
• 提供全自动的静态代码分析能力：集成 Maven Ant Gradle 以及持续集成工具 Atlassian Bamboo Jenkins Hudson 等；
• 集成外部工具：JIRA Mantis LDAP Fortify 等
• 具备插件的扩展机制
• 实现通过 SQALE 方法论来计算技术负债（technical debt）

集成 Sonar 的持续集成架构

图 1 所示为本实施方案中基于 Build Forge，并通过集成 Sonar 的持续集成架构图，其中的组件为：

• 构建调度：通过 Build Forge 实现对不同项目持续集成作业的调度；
• 构建引擎：通过调用 RTC 的 Jazz Build Engine 获取源代码，并进行编译和构建；
• 静态静态扫描：使用 Sonar 调度代码静态分析引擎进行代码扫描分析；
• 自动化测试：使用 JUnit 执行单元测试用例，在具体的实施中，可以通过 Sonar 调用，在执行之后，单元测试覆盖率相关的数据就会被存放到 Sonar 的数据库中；
• 启动 ETL：使用 Rational Insight 中的 ETL 组件 data manager 将 Sonar 的静态分析结果数据以及单元测试结果数据进行增量抽取并保存到数据仓库；
• 质量报表发布：将质量度量报表发布到多个平台（PC 端、手机端和 TV 端）。

图 1. 集成 Sonar 的持续集成方案架构

通过该持续集成架构，可以在持续集成的过程中，不断获取增量的度量数据，并根据该数据生成实时的代码质量度量数据，从而在持续集成的过程中将代码质量透明化。

基于 Sonar 的代码质量度量实施方案

整体方案介绍

在整个 DevOps 的工具平台中，Sonar 主要完成的是对具体代码目录 / 文件的静态代码扫描并获取对应的度量指标，但是从度量的角度，还需要进行各个维度的统计，包括扫描时间的统计等，这些信息显然需要从 RTC 和 Build Forge 中获取。同时，在具体的报表展示方式中，针对不同的用户群以及不同的度量目的，都需要使用不同的展示方式，比如手机端会比较便利，PC 端则可以查看比较详细的数据，TV 端则方便对整个团队的及时提醒，因此，在具体的报表展示上，也需要实现不同的展示方式。 结合上一节所总结的需求并基于这几点的考虑，在具体的实施中，本文设计了图 2 所示的实施方案。其中，ETL 模块会由持续集成的调度引擎触发，增量地从 Sonar，RTC，Build Forge 三个产品各自的数据库进行数据清洗、抽取、转化并存放到一个统一的数据仓库中，基于该仓库，再实现不同客户端的报表展示。在 ETL、数据仓库管理以及 PC 端报表展示中，本文均采用了 Rational Insight，而对于手机端报表和 TV 端报表，则采用通过定制开发的方式进行，为了给手机和 TV 端提供相应的数据格式，本文实现了一个统一的数据适配器，用于为手机和 TV 端提供所需要格式的报表数据。

图 2. 基于 Sonar 的代码质量度量整体方案

代码质量度量指标选择

Sonar 中针对各种程序语言，内置了大量的静态代码扫描规则：

• 重复的代码块
• 失败的单元测试
• 不足的分支单元测试覆盖率
• 不足的注释密度
• 不足的单元测试行覆盖率
• 跳过的单元测试

这些规则由于对所有语言是共用的，因此被放在一个公共的存储库中，一旦激活了它们，就可以在静态分析的过程中，自动启用这些规则进行扫描。同时，如果启用了单元测试覆盖率的分析，则需要先在 Sonar 中配置对单元测试框架的调用。

针对静态代码扫描规则，Sonar 也已经内置了许多度量指标，如表 1 所示：

表 1. Sonar 主要度量指标

ID	度量指标	备注
1	技术债	SQALE 方法论计算的综合性度量指标
2	圈复杂度	圈复杂度是一种代码复杂度的衡量标准，可以简单归结为一个方法中’ if ’ , ’ for ’ , ’ while ’等块的数目 +1。圈复杂度大说明程序代码可能质量低且难于测试和维护，根据经验，程序的可能错误和高的圈复杂度有着很大关系。
3	代码量	程序代码行数
4	代码违规数	所违反的静态分析规则总数
5	代码重复数	重复的代码物理行数

在具体实施中可以根据项目不同的阶段来选择不同的度量指标作为主要的度量指标对项目代码进行度量，本文主要选取了上述 5 个指标进行分析。同时，为了能够直观的获取一个团队或者产品代码的整体的质量，Sonar 中还围绕技术债增加了技术债率和技术债等级两个指标。

技术债是通过 SQALE 方法论，根据代码各个具体的质量指标值计算而成的综合性度量指标，例如一个方法或者函数的代码行数越多，其技术债就越高；同理，一个代码文件的代码复杂度越高，其技术债也会越高。

技术债率公式为：技术债率 = 总技术债 / 总代码行数

使用技术债率进行统计可以使得企业中的所有团队的度量值维持在同一个水平上，技术债率的取值在 [0,1] 之间。为了设定改进目标和图表的直观性，可以使用区间作为技术债等级对团队进行评级。典型的技术债等级如下：

• A 级，技术债范围 [0,10%] ，绿色表示
• B 级，技术债范围 (10%,20%] ，黄色表示
• C 级，技术债范围 (20%,30%] ，棕色表示
• D 级，技术债范围 (30%,50%] ，红色表示
• E 级，技术债范围 (50%,100%] ，黑色表示

数据仓库设计

在数据仓库的选择上，各种商务数据库以及开源数据库均可作为底层数据存储，设计数据仓库需要考虑分层，分模块的数据库结构。数据仓库一般包括 ODS 层和 DW 层数据仓库架构。

操作数据存储 ODS（Operational Data Store）是数据仓库体系结构中的一个重要部分，ODS 具备数据仓库的部分特征和 OLTP 系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。ODS 的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从 ODS 中进行，从而降低业务系统的查询压力。

DW 层物理模型分为星型和雪花型两种。所谓星型，就是将模型中只有一个主题，其他的表中存储的都是主题的一些特征。大部分设计应采用星型。使用事实表来存放质量指标等统计信息。使用维度表来存放组织，语言等技术信息。

ETL 设计

使用商业的 ETL 工具或者 Java 程序可以做数据的清洗，抽取，转化等。将 DevOps 项目中 RTC 产生的数据和 Sonar 产生的数据使用 ETL 工具抽取到数据仓库中。在具体实施时，本文采用了 Rational Insight 内置的 Data Manager 组件，它主要负责将各应用的数据抽取到度量数据仓库中。

Insight 内置的 Data manager 是成熟的数据抽取、变形、加载（Extract,Transform,Load）工具，主要功能是将各种异构数据源中的数据抽取并处理，包括过滤、变形、星形模式转换、雪花形模式转换、数据仓库结构变形等等处理，然后将处理后的结果导出到不同的数据库、数据仓库、数据集市或数据文件中。在实际应用中使用 Data manger 做数据处理非常方便和快捷。

图 3 显示了针对 Sonar 度量结果进行数据抽取的数据处理 Job。

IBM Insight 产品提供了图形化的 ETL 工具，使用图形拖拽连接即可方便的进行多层次的数据流的组建以及设计，在关键节点使用少量代码即可实现企业级的高效的数据清洗和抽取。

• 绿色三角形组件为 ETL 开始节点；
• 中间的三个齿轮组件为三种不同的 Sonar 数据的抽取；
• 最后的 SQL 组件为 ETL 结束的后处理，如写入数据更新时间等；

图 3. Data Manager 中的数据处理 Job

组织架构维度和时间维度

针对不同客户不同级别团队对度量指标的不同关注，在具体实施时，需要将本文所定义的度量指标根据组织架构不同级别进行统计，比如可以按照组织级，部门级，项目组等三个级别分别进行统计。每个级别按照技术债率公式进行统计和汇总，每个级别都可以显示代码行数，技术债率和技术债等级，不同的级别之间实现了数据的 “上卷” ， “下钻” 和 “切片” 。

而从时间维度，事实表也需要按照时间维度组织数据的汇总，一般可以设计 5 个层级，当前，一周前（7 天），半月前（15 天），1 月前（30 天），3 月前（90 天）。

基于 Sonar 的代码质量度量报表展示

PC 端的数据展示

基于 Insight 的报表系统，可以在 PC 端直接显示定制的代码质量度量报告，图 4 所示为通过技术债率及技术债等级两个指标出发对产品代码质量进行度量时，从整个组织级角度看到的各个开发团队的代码质量状况。其中，每个柱状体表示的是一个开发团队的代码技术债率，X 轴为各个开发团队名称，Y 轴表示的是其技术债率值。每个柱状体的不同颜色表示了不同团队代码质量所处的技术债等级。

在整个 DevOps 的交付工具平台中，通过这样一个不断演进的代码质量报表，就可以在持续开发的过程中，从企业的组织级层面及时全面地了解到不同团队的代码质量状况。

图 4. 各个开发团队的代码质量度量整体概况图

对于每个团队下属部门的代码质量状况，则可以通过单击图 4 中某个团队的的柱状图进行下钻显示。在下属部门中，更为重要的其实是需要获取那些代码质量需要提高的部门，并且通过代码质量的变化状况进行持续跟踪并督促改进。如图 5 就显示了一个开发团队下属各个部门的技术债率的分布柱状堆积图。该图只显示技术债级别在 B 级以下部门的技术债分布图。其中，红色表示在一段时间内（图中是 30 天）该部门的技术债率提升量，而绿色则表示在一段时间内该部门的技术债率下降量。通过这种横向比较可以看到一段时间内各个部门代码质量的变化情况。

同时，通过每个部门的代码质量柱状图可以再继续下钻到个人甚至代码代码文件上，也可以通过更为详尽的报表定位出具体需要修改的代码文件及位置。

图 5. 技术债率分布柱状堆积图

图 5 中的组件为：

• X 轴：开发部门名称；
• Y 轴：技术债率，增长率堆积；
• 颜色：增长和下降堆积；

PC 端的这些图表的共同特征是数据比较详细，也可以通过不断的下钻或上钻查看不同级别团队的代码质量状况，以方便跟进追踪。

TV 端的数据显示

PC 端的数据虽然详尽，但从组织级层面上看，对于高级的管理层来说，PC 端的访问过于麻烦复杂，也不方便，另一方面则除了详细的报表外，也需要一个全局的图表来直观地查看各级团队的代码质量情况。目前，很多企业均配备了大屏触摸显示器。根据这个需求，本文设计了一个全局的雷达图来显示企业中不同级别团队的所有开发组的质量情况。

图 6 所示是一个具有 4 层组织架构企业的质量雷达图，四层的雷达图使得不同部门的管理层既能从中看到整体的技术债得分，也能看到个体的得分，还能看到个体占据整体的比重。同时点击各个扇形可以下钻到各级部门和团队。其中图 6 的各个部分为：

• 环形面积大小：表示代码行数比例，面积越大，则代码行数占比越大；
• 环形颜色：表示技术债率等级；
• 圆心（最内圈）：表示整个组织级的代码总行数以及技术债率值；
• 第一层环：表示一级团队各自的代码行数以及技术债率值；
• 第二层环：表示下一层开发部门各自的代码行数以及技术债率值；
• 第三层环（最外层环）：表示各个项目组的代码行数以及技术债率值。

图 6. 具有 4 层组织架构的企业质量雷达图

通过 TV 端的这样一个图，高级管理层就可以很方便、直观的了解到整个组织各个团队的代码质量状况。

移动端的数据展示

随着智能手机的大面积普及，手机端的报表可以提供 PC 以及 TV 端所提供不了的及时和方便性，同时，手机端的报表也需要根据手机的特点，尽量选用简单的报表进行实现。在报表的开发中，可以使用 HTML5 的技术来展示，支持 HTML5 的开源图表控件有很多，本例中使用了 Highcharts 作为图表工具。

Highcharts 是一个非常流行，界面美观的纯 Javascript 图表库。它主要包括两个部分：Highcharts 和 Highstock。Highcharts 可以为您的网站或 Web 应用程序提供直观，互动式的图表。目前支持线，样条，面积，areaspline，柱形图，条形图，饼图和散点图类型。Highstock 可以为您方便地建立股票或一般的时间轴图表。它包括先进的导航选项，预设的日期范围，日期选择器，滚动和平移等等。使用 HTML5 展示的图表可以直接显示在移动端。

Highcharts 沿用 jQuery,MooTool 以及 Prototype 等 Javascript 框架来处理基本的 Javascript 任务。只需要在页面头部引用两个 JS 文件即可使用。

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js" type="text/javascript"></script>

<script src="/js/highcharts.js" type="text/javascript"></script>

在具体的实施中，本文通过一个数据适配器（Java 开发）将数据仓库中的数据抽取成静态 Json 格式的文件，并将生产的数据文件发布到亚马逊，ibm bluemix 等云平台中，从而通过云平台上基于 Highcharts 搭建的 Web 服务器实现了手机端对报表数据的访问。

实施收益总结

根据本文的实施经验，通过持续集成结合 Sonar 的质量改进方案使得

• 多渠道的图表展示使得管理层能够更及时的整个项目的质量情况；
• 多种图表的设计使得团队能在多个维度来查看质量数据；
• Insight 做 ETL 抽取，多种技术做前台展示，使得数据的展示更加方便和迅速；
• 代码静态分析扫描工具 Sonar 的准确扫描，使得质量数据更加准确；

经过一段时间的质量跟踪和改进，能够持续改进项目的代码质量。