Jenkins搭建持续集成环境方法介绍（三）

本文继承上文，在 Jenkins 项目已经创建好的基础上，介绍 Jenkins 持续集成环境的一些常见功能的用法介绍。

这里说的常见用法如：发布测试报告、发送构建结果邮件、发送圈复杂度检查报告等。

1 发布gtest测试报告

发布（gtest）测试报告属于 Jenkins 默认提供的功能，无需安装插件。

我们在项目配置中，点击“增加构建后操作步骤”、选择“Publish JUnit test result report”，进行发布测试报告的设置，如下图：

在上图中，在“测试报告（XML）”框中填写需要项目生成的测试报告路径及文件。例如：现有一项目的代码位于 code/ 目录中、测试报告为 xml 格式、测试报告生成的位置是 code/test/test_results，那么我们就可以填写“code/test/test_results/*.xml”。

另外，可以勾选“保留长的标准输出/错误”。

完成上面的测试报告发布设置后，在构建项目后，我们可以在项目的构建报告中查看到测试报告检查结果，如下图：

说明：本文中使用的测试报告是通过 gtest 测试框架生成的，gtest 生成测试报告的方法，不属于本文的介绍范围，可参考其他资料进行了解。

2 发送构建邮件

我们使用 Jenkins 默认提供的邮件通知服务，来实现发送构建邮件的功能。

2.1 系统设置

1. 在 Jenkins 主页点击“系统管理”、“系统设置”，进入到系统设置页面，然后设置“Jenkins Location”，如下图：

在上图中，设置“系统管理员邮件地址”，此邮件地址需要与后续“SMTP认证”时使用的“用户名”一致。

2. 设置邮件通知的详细内容，如下图：

说明：正常情况下，邮件通知属于 Jenkins 的默认提供功能，不过如果在系统设置中没有找到“邮件通知”的相关设置，那么就需要查看一下邮件插件（Mailer）是否已安装，若未安装，则需手动安装该插件。

在上图中，根据实际情况填写相应的内容：

• SMTP服务器：企业的发件服务器名称。例如使用 Foxmail 邮箱，可以在“系统设置”、“账号”中查看发件服务器信息，如下：
  
• 用户默认邮件后缀，与上图中的“账号”邮件的后缀保持一致即可；
• 用户名和密码：使用企业邮箱的用户名和密码即可；

在完成上述配置后，可通过勾选“通过发送测试邮件测试配置”，然后在“Test e-mail recipient”中填写收件人邮箱，点击“Test configuration”，测试我们对邮箱的配置是否生效。如果收件人邮箱收到了测试邮件，说明我们的邮箱配置生效了。

2.2 项目配置

在完成前面的系统配置后，我们还需要针对特定的项目进行邮件设置。

选择具体的项目，点击“配置”，进行项目配置页面，点击“增加构建后操作步骤”，选择“E-mail Notification”，如下图：

在上图中，在“Recipients”中填写收件人邮箱地址，即可实现发送项目构建邮件的功能了。

如果想在每次不稳定（unstable）的构建后，都发送邮件通知，则勾选“每次不稳定的构建都发送邮件通知”。

3 角色权限管理

我们通过使用 Role-based Authorization Strategy 插件，来实现 Jenkins 的角色权限管理功能。

3.1 用户管理

这里需要说明一下，如果使用 svn 管理源码，那么只要提交过 svn 代码并在 Jenkins 中进行过构建，那么该用户的信息就会保留在 Jenkins 中了，如下图：

以此为基础，可以很方便地进行用户管理了。点击上图中的某个用户名称（如xxb），则进行到该用户的设置界面中，如下图：

在上图中，点击“设置”，对该用户进行管理，如下图：

在用户设置页面，主要设置该用户的密码，然后点击“保存”，即可完成对该用户的设置操作。

此时，我们就可以使用该用户登录 Jenkins 了，如下图：

3.2 用户权限控制

在上一步添加了一个 Jenkins 用户之后，使用该用户登录 Jenkins 时，发现该用户有很多操作权限，这显然不利于 Jenkins 的系统安全，所以，我们需要控制该用户的权限。

3.2.1 安装插件

安装 Role-based Authorization Strategy 插件，如下图：

插件安装完成后，需要重启 Jenkins。

3.2.2 全局安全设置

安装完上面的插件后，进入 Jenkins 主页中，点击“系统管理”、“全局安全配置”，进入全局安全配置页面，如下：

在上图中，主要是将“授权策略”修改为“Role-Based Strategy”，即使用我们前面安装的插件进行用户权限控制。

点击“保存”。

3.2.3 管理、分配角色

选择了授权策略之后，我们就需要进行具体的角色管理了。进入 Jenkins 主页中，点击“系统管理”，能看到“Manage and Assign Roles”功能，如下图：

点击上图中的“Manage and Assign Roles”，转到具体的角色管理页面，如下图：

1. 在这里，我们首先点击“Manage Roles”，进行角色管理。我们首先需要新建一个角色（如developer），如下图：

然后，为新建的角色（developer）根据实际需要分配权限，如下图：

在上图中，我们为 developer 角色分配了项目构建权限、Jenkins 服务信息读取权限。（我们能够看到，admin角色默认拥有所有权限）

点击“save”保存该 developer 角色信息。

2. 然后，回到我们“Manage and Assign Roles”页面，点击“Assign Roles”，如下图：

进入“Assign Roles”页面，为 Jenkins 用户分配指定的角色，如下图：

在上图中，我们看到了刚刚添加的新角色 developer。我们将前面创建的用户xxb设置为 developer 角色。

点击“save”保存设置。至此，我们就完成了对于用户xxb的权限控制。此时，我们再次使用xxb用户登录 Jenkins，发现其权限发生了变化，如下图：

从上图中可以看到，xxb用户不再拥有“创建任务”、“系统管理”等功能，这说明我们对于该用户的权限控制生效了。

4 圈复杂度

我们通过 CCM 插件实现发布代码圈复杂度报告的功能。

4.1 安装插件

安装插件 CCM，CCM 插件信息如下图：

4.2 生成代码圈复杂度

这里需要说明的是，Jenkins 的 CCM 插件只是一个圈复杂度报告的分析和发布工具，其本身并不具备生成代码圈复杂度的功能，所以在这里我们还需要一个生成圈复杂度的工具。

4.2.1 编译生成圈复杂度工具

检查代码复杂度的工具有很多，本文选择了 github 上的一个 ccm 工具，github 链接为： https://github.com/jonasblunck/ccm

按照该链接中的指导，最终编译（需要使用vs进行编译）出检查代码圈复杂度的程序“CCM.exe”，该程序是 Windows 程序，为了能在 Linux 运行，我们需要在 Linux 上安装 mono，如下：

mono-core-4.6.2-4.el7.x86_64

安装 mono 之后，我们就可以在 CentOS 7 上运行 CCM.exe 了。

我们将圈复杂度相关的文件上传到 Jenkins 服务器上，下图是圈复杂度工具在 Jenkins 构建环境中的信息：

[[e-mail]_APP /var/lib/jenkins/workspace/account_system_CI/ci]# l
total 56
drwxr-xr-x 2 root root    69 Aug 28 19:11 ./
drwxr-xr-x 5 root root    39 Aug 28 19:10 ../
-rw-r--r-- 1 root root   543 Aug 28 14:45 account_sys_ccm.config
-rw-r--r-- 1 root root 31232 Aug 10 08:55 CCMEngine.dll
-rw-r--r-- 1 root root 19456 Aug 10 08:54 CCM.exe
[[e-mail]_APP /var/lib/jenkins/workspace/account_system_CI/ci]# 

对于上图中的几个文件进行以下说明：

• CCM.exe：编译 github 上的源代码生成的可执行文件；
• CCMEngine.dll：编译 github 上的源代码生成的可执行文件；
• account_sys_ccm.config：圈复杂度的配置文件，供 CCM.exe 使用；

4.2.2 编写CCM配置文件

这里的 CCM 配置文件是核心，CCM.exe 读取 CCM 配置文件的内容，进行具体的圈复杂度分析。有以下两种方式来了解 CCM 配置文件的写法说明：

1. 通过在 CentOS 7 命令行运行“mono CCM.exe”，可得到 CCM 配置文件的示例，以及相关元素的描述，如下：

2. 从 github 上获取的源码中，有一个“readme.doc”文件，在该文件中也介绍了 CCM 配置文件的元素信息描述。

本文中使用的 CCM 示例配置文件信息如下：

[[e-mail]_APP /var/lib/jenkins/workspace/account_system_CI/ci]# cat account_sys_ccm.config 
<ccm>
  <analyze>
    <folder>../code</folder>
  </analyze>
  <exclude>
    <folder>../code/preplatform</folder>
    <folder>../code/test</folder>
  </exclude>
  <recursive>yes</recursive>
  <outputter>Xml</outputter>
  <threshold>15</threshold>
  <numMetrics>20</numMetrics>
  <suppressMethodSignatures>yes</suppressMethodSignatures>
  <switchStatementBehavior>IgnoreCases</switchStatementBehavior>
  <fileExtensions>
    <fileExtension>.cpp</fileExtension>
    <fileExtension>.h</fileExtension>
  </fileExtensions>
</ccm>
[[e-mail]_APP /var/lib/jenkins/workspace/account_system_CI/ci]# 

4.2.3 运行CCM

编写完CCM的配置文件后，我们就可以运行CCM程序，来生成圈复杂度报告了。在 CentOS 7 中，CCM 程序的运行命令如下：

mono CCM.exe account_sys_ccm.config > ccm.xml

通过上面的命令，我们就可以根据配置文件 account_sys_ccm.config 的内容，生成一份圈复杂度报告了，并将报告的内容保存在 ccm.xml 中。这个 ccm.xml 就是我们 Jenkins 服务需要发布和展示的圈复杂度报告了。

说明：在实际的持续集成环境部署中，我们需要把 CCM 的程序运行过程放入 Jenkins 的构建过程中，一般都是在代码编译后，再生成圈复杂度报告的。

4.3 发布圈复杂度检查结果

我们针对某个项目进行设置，实现发布圈复杂度报告的功能，具体设置信息如下：

在上图中的“CCM results”栏中，填写使用 CCM 工具生成的圈复杂度报告的位置（注意这里是相对于项目根目录的位置）。同时，还可以根据需要，填写圈复杂度检查结果对于本次构建的影响（unstable、failed）。

至此，我们对于 Jenkins 中集成代码圈复杂度检查的设置就结束了。

完成上述设置后，进行项目构建后，可以在构建报告中找到圈复杂度检查结果，如下：

我们可以通过点击上图中的告警信息，查看具体的圈复杂度检查结果。