标签：
续上。。。。
第二章 部署示例：Jenkins and PRQA 工具
第一节 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个顶级阶段：
构建阶段和构建后的阶段需不需要包含多个步骤，取决于构建/测试的需求，以及所安装的插件。
一个简单的事件可能要进行以下配置：
在执行事件的时候，Jenkins会从存储库中检出最新版本的代码，然后在shell中执行“make”命令，并将生成的可执行文件复制到主机上。如果其中某一步执行失败了，那么后面的步骤就都无法执行了，所以事件的状态就会显示为“失败”。只有当所有的步骤能准确无误地执行完成之后，该事件的状态才可能显示为“成功”。如果能达到这个最基本的水平，就可以用Jenkins安排夜间构建。
入门指导
Jenkins的入门很简单 —— 它可以以一个完整、可运行的网络应用程序的存档文件形式存在。该文件可以下载并执行 —— 但是，为了正确安装，要将它以服务/后台程序的形式安装，并按权限以用户的身份执行。
第二部分：利用PRQA Jenkins插件进行静态分析
PRQA的Jenkins插件，可与我们的静态分析工具QA·C 或QA·C++一起使用，来对源代码进行分析。在构建完成之后的阶段，该插件自动执行以下主要任务：
分析阶段的工作可以通过“依赖模式”来开展——所以只需要对在上次分析之后有所改变的文件进行分析，从而尽量减少项目的分析时间。也可以在构建阶段进行分析（比如Makefile集成），并向插件提供列表，列出所有经过分析的文件，让插件可以识别到已分析过的文件。
如图5，插件将概要信息显示在事件网页上。
图5 使用PRQA插件的事件（为适应页面大小改变了一下格式）
遵从度和每次构建时产生的信息总数都能以曲线图形式显示出来，这样就很容易看到编码规范的违规趋势。合规汇总表显示项目和文件的合规百分比（这些数据可从QA·C/QA·C++合规报告中获取，报告会详细指出不符合编码规范的代码）以及所产生的信息总数。第二个表显示的是各个级别的分解信息。插件会自动存档所有报告，所以在项目合规状态方面能够提供更详细的信息。
违规数量的临界值可设置为绝对值，比如0，表示不允许有任何违规行为。此外，还可以设置执行临界值的信息级，这样就可以将信息的严重性等级考虑在内。如果代码需要的维护工作不是特别复杂，样式方面的问题也不是很严重，就可以视为通过；但是如果代码有严重的问题，就不能通过。
能够将分析结果上传到QA·Verify是该插件最强大的功能。将结果上传之后，开发人员就可以看到深入的分析结果，包括带注解的源代码，这些结果中会显示违反编码规范的具体位置。该插件还允许添加、管理和报告违反编码规范的代码，并可自动校对代码是否遵循编码规范，如MISRA C。QA·Verify也会向其它项目相关者（比如，管理员，甚至是客户）公开这些质量信息。图6展示了PRQA工具是如何与Jenkins配合使用的。
图6：Jenkins与QA·C，QA·C++，QA·Verify配合使用的情况
开发人员像平常一样提交代码（代码先提交到临时库中，当代码通过所有测试时，再转入正式库）。要配置持续集成服务器，以便可以对原代码进行 QA·C 或 QA·C++分析。概要信息，如：通过集成服务器可以了解代码是否遵循了最佳编码惯例，而且，分析结果还可以自动上传到QA·Verify。这样开发人员就可以通过网页浏览器看到带注释的源代码，从而准确找到不符合编码规范的地方，以便在重新提交代码之前修复这些问题。
其它项目相关人员可以在QA·Verify中看到带注释的源代码，但是管理层和质检人员等，会希望了解更多其它更高级别的数据。管理层可能不太想看源代码，他们感兴趣的应该是：代码中有多少问题——问题的数量是呈上升还是下降趋势。因为可以看到项目中不同级别的信息，管理层在做决定时，就可以根据必要的数据来判断应该如何重新分配资源。
结论
通过持续集成，很容易就能够“循序渐进地”将最佳编码惯例应用于静态分析中。持续集成能够让集成和测试环节贯穿整个开发阶段，这将为开发带来很多裨益。因为这样有利于在问题变得严重之前尽早解决，还能保证存储库中的代码一直处于高质量状态。
使用插件，很容易能够将PRQA静态分析工具QA·C和QA·C++与Jenkins持续集成结合起来，从而迅速给出反馈，指出代码是否遵循了编码规范和最佳惯例。该插件还能够将结果上传到QA·Verify，以便进行深入的调查研究和趋势分析。
将持续接触和PRQA的静态分析工具结合起来能够帮助提高代码的交付质量，并且能保证在规定时间和预算范围内实现交付。
标签：
原文地址：http://www.cnblogs.com/trinitytec/p/4864583.html
