通过静态分析和持续集成 保证代码的质量 （Helix QAC）2

续上。。。。

 

第二章 部署示例：Jenkins and Helix QAC工具

第一节 Jenkins 作为持续集成系统

现在有很多持续集成工具，既有免费的，也有商业的。最近的研究显示，Jenkins正发展成为最受欢迎的持续集成工具。Jenkins是Hudson持续集成系统的一个分支，但是Jenkins拥有最活跃的生态系统。

在MIT许可下，Jenkins是免费的，但是和一些开源软件一样，Jenkins也有付费版本，并会提供技术支持。虽然Jenkins是一个开源项目，但是对核心代码所作的所有修改，都由核心提交者严格把控，其中一位核心提交者就是项目架构师Koshuke Kawaguchi。

系统概述

Jenkins是用Java写的，由一个很小的内核和一个内置网站服务器组成。大多数用户与Jenkins的互动都是通过常规网页浏览器来实现的，不需要安装特别的客户端软件。

灵活性是优质持续集成系统的一个主要特性，它能够满足所有公司的业务要求。Jenkins有两个非常重要的结构特点，使得它既可自定义又可扩展：主/从分布式构建结构和插件。

主/从结构

虽然Jenkins经常以主/从安装形式配置，但其实Jenkins也可以部署在一台独立的电脑上。由一个主机控制何时进行代码的构建和测试，并为用户提供接口。Jenkins上的所有任务都叫做事件。由一个或多个从属机器执行实际的构建和测试工作。构建（工件，如最终的二进制文件、程序包、测试报告，等等）产生的所有重要结果，都会从从属机器转移到并保存到主机上。中间文件，如目标代码，还是保留在从属机器上（会定期移除）。主机会保留所有的历史构建结果，因而可以判断出项目的趋势。

从属机器没有什么特别的 —— 只要是装有所需的开发和测试工具的现成电脑就可以了。从属机器可以运行与主机不同的操作系统——这对于为多平台编写代码有重要意义。从属机器也可以连接到硬件设备，以便可以将嵌入式代码下载到实际设备中进行测试。从属机器也不一定要是实际机器，现在虚拟机正在越来越广泛地被用做从属机器，采用基于云的解决方案，因为这种方法成本较低。

插件

Jenkins完成的大多数自定义任务都是通过插件来实现的。Jenkins内核中定义好的应用程序界面（API），可以通过安装插件来丰富图形用户界面（GUI）的配置选项，这些功能在使用的时候就好像是内核的一部分一样。

现在有超过800（正在增多）种插件，插件涉及很多方面，包括：版本控制系统的交互作用、代码构建、测试、报告、工件管理。通过安装相关的插件，可以定制Jenkins，以适应项目的构建和测试需求。

仪表盘

Jenkins可通过仪表盘模式显示所有事件的整体状态。每个事件的状态都以点状形式显示，颜色表示上次执行的状态（在默认情况下，红色表示失败，黄色表示不稳定，蓝色表示成功——但是和Jenkins中的大多数功能一样，颜色也是可以自定义的）。闪烁的点表示该事件正在构建中。用“天气”的标志，通过晴天（太阳）、阴天（雷云）等天气状态，以比较直观的形式总结出最近的构建情况。

仪表盘会显示事件队列 —— 待构建事件的列表。同时还会显示从属机器的状态，指出哪些事件是不运行的，哪些正在执行。图4显示的是Apache Software Foundation的Jenkins仪表盘。

图4 Jenkins仪表盘

图4显示的是Jenkins仪表盘。右侧显示的是事件列表。左下方显示的是从属机器列表，从属机器列表的上方显示的是构建队列。

事件

每个事件都有一个页面记录构建的历史情况，通常情况下，是一些图形化输出，显示测试状态以及与最近的构建工件、代码修改及其它重要或相关的数据。

一个事件可被拆分成3个顶级阶段：

1. 构建前。在这个阶段，会从存储库中检出最新的代码。通常是先检查存储库，看是否有新代码提交进来，如果有就检出。也可能是根据时间安排或在完成了其它事件之后，对存储库中的代码进行检出。
2. 构建中。这一步在大多数实际工作完成之后开始，包括：从编译和耦合到对代码进行测试。Jenkins会记录所有命令的控制台输出，以便排除故障。
3. 构建后。在这一过程中，需要对构建好的代码进行进一步测试。同时还要收集并解析测试结果，最后将结果显示出来。并将所需的工件存档到主机上。

构建阶段和构建后的阶段需不需要包含多个步骤，取决于构建/测试的需求，以及所安装的插件。

一个简单的事件可能要进行以下配置：

1. 构建前: 版本控制系统应用程序，存储库的路径，模块名称
2. 构建中：包含简单的“make”命令的shell执行步骤
3. 构建后：对工件进行存档时要使用构建阶段生成的可执行文件的名称。

在执行事件的时候，Jenkins会从存储库中检出最新版本的代码，然后在shell中执行“make”命令，并将生成的可执行文件复制到主机上。如果其中某一步执行失败了，那么后面的步骤就都无法执行了，所以事件的状态就会显示为“失败”。只有当所有的步骤能准确无误地执行完成之后，该事件的状态才可能显示为“成功”。如果能达到这个最基本的水平，就可以用Jenkins安排夜间构建。

入门指导 

Jenkins的入门很简单 —— 它可以以一个完整、可运行的网络应用程序的存档文件形式存在。该文件可以下载并执行 —— 但是，为了正确安装，要将它以服务/后台程序的形式安装，并按权限以用户的身份执行。

第二部分：利用PRQA Jenkins插件进行静态分析

Perforce的Jenkins插件，可与我们的静态分析工具Helix QAC一起使用，来对源代码进行分析。在构建完成之后的阶段，该插件自动执行以下主要任务：

1. 分析项目
2. 生成合规报告
3. 将项目中的信息总数与可配置的临界值进行对比，如果超过了该临界值，就将构建状态设置为“不稳定”：可以将其当作大门，阻止后续任务的执行。
4. 有选择性地将分析结果上传到QA·Verify中，这是PRQA的网络质量管理系统。

分析阶段的工作可以通过“依赖模式”来开展——所以只需要对在上次分析之后有所改变的文件进行分析，从而尽量减少项目的分析时间。也可以在构建阶段进行分析（比如Makefile集成），并向插件提供列表，列出所有经过分析的文件，让插件可以识别到已分析过的文件。

如图5，插件将概要信息显示在事件网页上。

图5 使用Helix QAC插件的事件（为适应页面大小改变了一下格式）

遵从度和每次构建时产生的信息总数都能以曲线图形式显示出来，这样就很容易看到编码规范的违规趋势。合规汇总表显示项目和文件的合规百分比（这些数据可从Helix QAC合规报告中获取，报告会详细指出不符合编码规范的代码）以及所产生的信息总数。第二个表显示的是各个级别的分解信息。插件会自动存档所有报告，所以在项目合规状态方面能够提供更详细的信息。

违规数量的临界值可设置为绝对值，比如0，表示不允许有任何违规行为。此外，还可以设置执行临界值的信息级，这样就可以将信息的严重性等级考虑在内。如果代码需要的维护工作不是特别复杂，样式方面的问题也不是很严重，就可以视为通过；但是如果代码有严重的问题，就不能通过。

能够将分析结果上传到QA·Verify是该插件最强大的功能。将结果上传之后，开发人员就可以看到深入的分析结果，包括带注解的源代码，这些结果中会显示违反编码规范的具体位置。该插件还允许添加、管理和报告违反编码规范的代码，并可自动校对代码是否遵循编码规范，如MISRA C。QA·Verify也会向其它项目相关者（比如，管理员，甚至是客户）公开这些质量信息。图6展示了PRQA工具是如何与Jenkins配合使用的。

图6：Jenkins与Helix QAC配合使用的情况

开发人员像平常一样提交代码（代码先提交到临时库中，当代码通过所有测试时，再转入正式库）。要配置持续集成服务器，以便可以对原代码进行Helix QAC分析。概要信息，如：通过集成服务器可以了解代码是否遵循了最佳编码惯例，而且，分析结果还可以自动上传到QA·Verify。这样开发人员就可以通过网页浏览器看到带注释的源代码，从而准确找到不符合编码规范的地方，以便在重新提交代码之前修复这些问题。

其它项目相关人员可以在QA·Verify中看到带注释的源代码，但是管理层和质检人员等，会希望了解更多其它更高级别的数据。管理层可能不太想看源代码，他们感兴趣的应该是：代码中有多少问题——问题的数量是呈上升还是下降趋势。因为可以看到项目中不同级别的信息，管理层在做决定时，就可以根据必要的数据来判断应该如何重新分配资源。

结论

通过持续集成，很容易就能够“循序渐进地”将最佳编码惯例应用于静态分析中。持续集成能够让集成和测试环节贯穿整个开发阶段，这将为开发带来很多裨益。因为这样有利于在问题变得严重之前尽早解决，还能保证存储库中的代码一直处于高质量状态。

使用插件，很容易能够将PRQA静态分析工具Helix QAC与Jenkins持续集成结合起来，从而迅速给出反馈，指出代码是否遵循了编码规范和最佳惯例。该插件还能够将结果上传到QA·Verify，以便进行深入的调查研究和趋势分析。

将持续接触和Perforce的静态分析工具结合起来能够帮助提高代码的交付质量，并且能保证在规定时间和预算范围内实现交付。