在把QAC接入Jenkins的时候，需要留意一点，就是它那个旧版的Jenkins插件，从某个版本号开始已经进入弃用状态了，虽然还在插件目录里放着，但新的项目，更建议优先去考虑命令行的方式，或者是Perforce静态分析相关的集成办法，这件事的核心，就是要把在本地能顺顺当当跑通的QAC分析流程，给挪到流水线里面去，并且让Jenkins能拿得到许可证、编译的环境、项目的配置，还有最后产出来的报告文件。

　　一、QAC怎么接入Jenkins

　　在把QAC往Jenkins里面接之前，得先在负责构建的那台机器上，把QAC本地的分析给跑通了，不要一上来，就直接动手去写Pipeline的脚本，不然的话，许可证、环境变量、编译的命令，还有项目的路径，这几样东西全都搅和到一块儿，到后面排查起来，会非常费劲。

　　1、要先去把构建的节点给准备好

　　在Jenkins的那台节点机器上，去把Helix QAC的客户端给装好，然后去把许可证的服务器给配置对，确认一下，在命令行里面，是能够正常地去执行那个分析命令的，一些旧一点的资料里也提到过，命令行工具就是被拿来，把PRQA的框架和工具，给集成到构建服务器里面去的，那些子命令，也是靠着它去执行的。

　　2、去把项目的扫描流程给理清楚

　　要先确定下来，这个项目，是直接从已经有的一份QAC工程上开始跑，还是打算在Jenkins的工作区里面，去重新创建一个临时的工程，一套比较常见的顺序是，先去把代码给拉取下来，然后把编译的环境给准备好，接着去执行QAC的同步或者是项目的更新，最后，再跑分析和生成报告，在一开始写命令的时候，不用弄得太复杂，先让一条分支、一个模块，能稳稳当当地跑通，就可以了。

　　3、把它给放进Jenkins的任务里面去

　　那种自由风格的任务，是可以在构建步骤里面，去添加执行Windows批处理命令，或者是执行Shell脚本的；而Pipeline类型的项目呢，则是在Jenkinsfile文件里面，去写好拉取代码、构建、QAC分析，还有报告归档，这么几个阶段，要是你用的是插件的方式，Jenkins的Helix QAC插件，是会提供一个专门用来发布报告的命令步骤的。

　　4、去把报告和结果给归档好

　　等到分析跑完了以后，去把QAC生成出来的HTML、XML，或者是其他格式的报告，给放到一个固定的目录里面去，然后通过归档构建产物这个功能，去把它们给存好，到了后面，要去做质量门禁的时候，再根据严重的级别、规则的分类，或者是新增问题的数量，去判断是不是要让这一次的流水线，给标记成失败。

　　二、QAC在Jenkins里运行失败了要怎么排查

　　QAC在Jenkins里面跑失败了，有不少时候，其实并不是QAC规则本身出了什么问题，而是Jenkins的那个运行环境，跟你自己手动登录上去的环境，它俩是不一致的，排查的时候，要先去看控制台打出来的日志，不要只是盯着那个红色的、表示失败的状态在那里看。

　　1、去检查一下许可证，是不是还能用

　　Jenkins用来跑任务的那个服务账号，跟你自己手工登录用的账号，可能根本就不是同一个人，你自己登上去能跑，可不代表Jenkins的节点，就能顺顺当当地拿到许可证，可以在Jenkins的脚本里面，先去执行一下检查版本和检查许可证的命令，去确认一下，服务器的地址、端口、防火墙，还有环境变量，这些东西，全都是正常的。

　　2、去检查一下工作区的路径

　　Jenkins每一次构建的时候，它的工作区路径，都是有可能会发生变化的，要是在QAC的工程里面，写死了那种绝对路径，那它就很容易找不到源码、配置文件，或者是编译的数据库，所以，更推荐的做法，是把源码的根目录、QAC工程的目录，还有报告要输出到哪个目录，这些全都给写成，是基于工作区的相对路径。

　　3、去检查一下编译的环境

　　QAC在分析C和C++项目的时候，常常是要依赖编译器、头文件在哪、宏都是怎么定义的，还有构建的脚本，要是Jenkins的节点上面，缺了编译的工具链，或者是没有去加载交叉编译的那套环境，那么在分析的时候，就会跑出来一大堆，像找不到头文件、宏没有被定义、源文件没有同步过来，这一类的报错。

　　4、去检查一下权限，还有缓存的那些东西

　　Jenkins用的那个账号，它得要有去读源码、往报告目录里写东西、创建临时目录，还有去访问共享盘，这些权限才行，另外，之前跑分析留下来的那些旧的中间文件，也有可能会影响到这一次的结果，在跑失败了以后，是可以去把工作区，还有QAC的临时目录，都给清理一下，然后再去做一次干干净净的构建。

　　三、QAC在Jenkins里怎样稳定运行

　　在把QAC接进了Jenkins以后，可不能只满足于，能跑成功一次就完事了，还得要让跑出来的结果，是可以被重复的、可以被追溯的，也是可以被好好地归档起来的，尤其是在车载软件、嵌入式项目，还有那种做MISRA检查的场景里面，流水线留下来的这些证据，是要能被后面做评审的人，给拿来重复使用的。

　　1、去把工具的版本给固定下来

　　QAC自身的版本、规则包的版本、编译器的版本，还有Jenkins节点所使用的那个镜像，这些东西，全都得给记录得清清楚楚的，因为一旦工具的版本发生了变化，那么就算是对着同一份代码，它跑出来的告警数量，也有可能会是不一样的，到了那个时候，可就不能把这种数量上的变化，给错判成是代码质量本身在变好了，还是变差了。

　　2、去把基线和增量的扫描，给拆分开来

　　在Perforce静态分析插件的文档里，是这么提到的，基线扫描，是用来做一次完整的扫描，然后把它发现的所有问题，全都给上传上去；而增量扫描呢，它的用途，是基于上一条基线，去把潜在的新冒出来的问题，给识别出来，这种模式，是很适合拿来做合并请求的那种质量门禁的，项目上，是可以先去建立一条基线，然后再把新增的那些高风险的问题，当成是阻断的重点。

　　3、把失败时候的现场，给保留下来

　　当Jenkins跑失败的时候，要记得去把控制台的完整日志、QAC自己打出来的日志、分析的报告、构建的命令，还有那些最关键的配置，都给留下来，不要只是在通知里面，简简单单地写一句“扫描失败了”就完了，要不然的话，做开发的人，是很难去判断，这到底是代码本身的问题、是环境出了问题，还是说，仅仅只是因为许可证，或者是路径，没搞对。

　　总结

　　要把QAC接入到Jenkins里面去，得先在构建的节点上，把命令行的分析工具，还有本地的分析，都给跑通了，然后再把它给放进Jenkins的任务，或者是Pipeline里面去，最后，再把报告给归档好，当它运行失败了的时候，要重点去查许可证、工作区的路径、编译的环境、文件的权限，还有那些旧的缓存，一种真正能称得上稳定的接入方式，是要把工具的版本、扫描的基线、增量的门禁，还有失败了以后的日志，这些东西，全都给纳入到流水线的管理里面去，而不是只把一条干巴巴的分析命令，给硬塞进构建的脚本里。