Jenkins 在 Tomcat 中的部署及代码静态检查工具集成

Posted 2021-04-07 DevOps时代

Jenkins 的简单部署

在安装了 Jenkins 运行所需的依赖（主要是 JDK）之后，可以通过如下步骤简单快速地部署 Jenkins：

下载 Jenkins.

打开终端并切换至下载目录。

运行命令 java -jar jenkins.war —httpPort=8080。

—httpPort 参数用于指定 Jenkins 服务运行的端口。这条命令将运行 Jenkins 服务。

打开浏览器并输入网址 http://localhost:8080。URL 中的端口需要与上面运行 Jenkins 时指定的端口一致。在浏览器中我们能看到 Jenkins 的页面了。

按照指示完成安装过程。安装插件，并对 Jenkins 做配置。

Jenkins 在 Tomcat 中的部署

虽然上面的 Jenkins 部署很方便快捷，但是服务管理却不是很方便。Jenkins 作为一个 Java Web 应用，其 war 包可以非常方便的部署在 Tomcat 容器中。Tomcat 在 Ubuntu 系统中的安装过程可以参考 Ubuntu 16.04 Tomcat 8安装指南 一文。

要在 Tomcat 容器中部署 Jenkins，只需将 jenkins.war 复制到 $TOMCAT_HOME/webapps，然后通过 URL http://yourhost/jenkins 访问即可。

如果 Tomcat 容器中只部署 Jenkins 服务，可以移除 $TOMCAT_HOME/webapps 目录中的所有内容，然后将 jenkins.war 放进这个目录中并重命名为 ROOT.war（注意大小写要保持一致）。

Tomcat 将展开这个文件并创建 ROOT 目录，然后我们应该可以在 http://yourhost 看到 Jenkins，而无需任何额外的路径（如果采用了 Tomcat 的默认配置，应该是 http://yourhost:8080）

如 Ubuntu 16.04 Tomcat 8安装指南 一文的介绍，如果为 Tomcat 建立了 systemd 服务文件，可以通过如下命令重启 Tomcat 服务：

$ sudo systemctl stop tomcat $ sudo systemctl start tomcat

并可以通过如下命令查看 Tomcat 的运行状态：

$ sudo systemctl status tomcat

在 Jenkins 服务启动之前，设置环境变量 JENKINS_HOME 可以指定 Jenkins 服务的主目录。这可以通过为 Tomcat 的 systemd 服务文件 /etc/systemd/system/tomcat.service 添加如下的行来实现：

Environment=JENKINS_HOME=/opt/tomcat/jenkins_home

这行配置在启动 Tomcat 容器之前，导出环境变量。

更多关于在 Tomcat 中部署 Jenkins 的内容可以参考 Tomcat - Jenkins - Jenkins Wiki。

nginx 反向代理

将 Tomcat 容器作为 Web 服务器不是那么的方便，通过 nginx 做反向代理会好很多。在 Ubuntu 中可以通过如下命令安装并运行 nginx：

$ sudo apt-get install nginx
$ sudo nginx

修改 nginx 的配置文件 /etc/nginx/nginx.conf，在 http 块的最后添加如下几行为 Jenkins 设置反向代理：

server {            listen 80;            server_name 59.111.103.32;            location / {               proxy_pass http://127.0.0.1:8080;                proxy_redirect off;                proxy_set_header Host $host;                proxy_set_header X-Real-IP $remote_addr;                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;                proxy_set_header X-Forwarded-Proto $scheme;            }        }

随后，就可以通过 http://yourhost URL，经过 nginx 访问 Jenkins 服务了。登陆之后，打开 Jenkins 左上角的 Jenkins -> Manage Jenkins -> Configure System Jenkins 全局配置页面，滚动到 Jenkins Location 的部分，正确配置 Jenkins URL：

Jenkins 作为一个强大的持续集成平台，其强大之处的重要体现就是，支持许许多多的插件，可以将功能强大的第三方工具集成进来，代码质量保障相关的工具，比如代码的静态检查工具，是其中比较常用的一些。

常用的代码静态检查工具有 PMD，FindBugs，android Lint，CheckStyle 和 SonarQube Scanner 等。

PMD
PMD 是一个可扩展跨语言的静态代码分析器。它查找常见的编程缺陷，如未使用的变量，空 catch 块，不必要的对象创建，等等。

此外它还包含 CPD，复制粘贴探测器。CPD 查找重复代码。

PMD 扫描 Java 和其它编程语言 的源代码，并查找像下面这样的潜在问题：

• 可能的 bugs - 空的 try/catch/finally/switch 声明

• 死码 - 未使用的本地变量，参数和私有方法

• 次优代码 - 无用的 String/StringBuffer 使用

• 过于复杂的表达式 - 不必要的 if 声明，可能可以写成 while 的 for 循环

  CPD，复制粘贴探测器，查找多种语言的重复代码：

• 重复代码常常是由复制粘贴产生的。这意味着，bugs 也被复制粘贴了。修正它们意味着，修正所有重复的代码。

在正式开始集成 PMD 之前，首先需要通过 Jenkins 左上角的 Jenkins -> Manage Jenkins -> Manage Plugins，在 Jenkins 中安装 PMD 的插件：

我们通过为 Jenkins Project 添加 Post-build Action 来集成 PMD。

打开 Jenkins Project 的主页，点击左边的 Configure 打开工程的配置页面，找到页面最下边的 Post-build Actions，点击 Add post-build action 的下拉箭头，并找到 Publish PMD analysis results，添加 PMD post-build action，如下图：

在 PMD results 输入框中输入 PMD 检查结果文件的路径，这个结果文件需要我们在构建期间调用 PMD 工具生成。配置了 PMD post-build action 之后，点击左下角的 Save 按钮保存退出配置。

使用 PMD 工具生成源代码的静态检查分析报告的方法如下：

$ cd $HOME $ wget https://github.com/pmd/pmd/releases/download/pmd_releases%2F6.2.0/pmd-bin-6.2.0.zip $ unzip pmd-bin-6.2.0.zip $ alias pmd="$HOME/pmd-bin-6.2.0/bin/run.sh pmd" $ pmd -d /usr/src -f xml -r pmd.xml -rulesets     java-basic,java-design

PMD 工具的 -d 参数用于指定项目的源码路径，-f 参数用于指定输出报告文件的格式，-r 用于指定输出报告文件的文件名，-rulesets 则用于指定检查规则集合。这个命令将产生名为 pmd.xml 的 XML 格式的检查报告，这也是 Jenkins 的 PMD 插件所支持的格式。

在下载并安装 PMD 工具之后，在 Jenkins 工程的构建脚本中执行 PMD 工具产生检查报告，如将 PMD 检查的功能集成进一个用 Python 写的构建脚本：

def run_pmd(wrapper_module_name, target_module_name):    if "PMD_ROOT_PATH" not in os.environ.keys():        print("Cannot find PMD")        return    pmd_root_path = os.environ["PMD_ROOT_PATH"]    pmd_cmd_path = pmd_root_path + os.path.sep + "bin/run.sh"    src_dir = wrapper_module_name + os.path.sep + target_module_name + os.path.sep + "src/main/java"    pmd_cmd_path = "%s pmd -d %s -f xml -r pmd.xml -rulesets java-basic,java-design" % (pmd_cmd_path, src_dir)    print(pmd_cmd_path)    os.system(pmd_cmd_path)

Jenkins 工程在构建结束之后，将根据配置的 PMD results 路径查找 PMD 检查的结果，并将结果展示在 Jenkins 工程的主页面上，如下图所示：

点击 PMD Trend 将可以看到 PMD 检查的详细结果，如下图：

关于 PMD 工具用法更详细的内容，可以参考它的 主页 和 官方文档。

FindBugs
FindBugs 是另一个强大的静态代码检查工具，它主要用于查找 Java 代码 中的 bugs，它查找 正确性 bugs，糟糕的做法及 Dodgy 等问题。

与在 Jenkins 中集成 PMD 类似，同样需要先在 Jenkins 中为 FindBugs 安装插件：

然后配置 Jenkins 工程，添加 post-build action Publish FindBugs analysis results，如下图：

FindBugs results 输入框中需要输入 FindBugs 工具代码检查的结果文件。Jenkins 将在构建结束之后，扫描这个文件，并在页面中展示出来。

在 Jenkins 工程的构建阶段，需要调用 FindBugs 工具生成检查报告，方法如下：

$ cd $HOME $ wget https://jaist.dl.sourceforge.net/project/findbugs/findbugs/3.0.1/findbugs-3.0.1.tar.gz $ tar xvf findbugs-3.0.1.tar.gz $ findbugs-3.0.1/bin/findbugs -textui -low -xml -output findbugs.xml module/build/intermediates/bundles/debug/classes.jar

FindBugs 提供了两种用户界面，分别是 GUI 和命令行用户界面，在 Jenkins 的构建脚本中，我们以命令行界面执行 findbugs，这通过 -textui 参数来指定。-low 参数用于指明希望输出所有类型的问题，-xml 参数用于指定生成的检查报告的文件格式，-output 参数指明输出文件名，最后是模块编译生成的 class jar 文件。

在 Jenkins 服务器上下载安装了 FindBugs 工具之后，集成代码检查过程进 Python 构建脚本的方法大体如下：

def run_findbugs(wrapper_module_name, target_module_name):    if "FIND_BUGS_ROOT_PATH" not in os.environ.keys():        print("Cannot find findbugs")        return    findbugs_root_path = os.environ["FIND_BUGS_ROOT_PATH"]    findbugs_cmd_path = findbugs_root_path + os.path.sep + "bin/findbugs"    class_file_path = wrapper_module_name + os.path.sep + target_module_name + os.path.sep + "build/intermediates/bundles/debug/classes.jar"    findbugs_cmd_path = "%s -textui -low -xml -output findbugs.xml %s" % (findbugs_cmd_path, class_file_path)    print(findbugs_cmd_path)    os.system(findbugs_cmd_path)

在 Jenkins 的构建任务结束之后，它扫描 FindBugs 的检查结果，并展示出来：

点进去可以查看更详细的找到的问题：

关于 FindBugs 更详细的内容，可以参考其主页和文档。

总结一下 PMD、FindBugs 集成进 Jenkins 的流程：

• 全局 Jenkins 配置方面，为相应的代码静态检查工具安装插件。

• 在 Jenkins 工程配置中，为相应的代码静态检查工具添加 post-build action，配置检查结果文件的存放路径。

• 为 Jenkins 服务器下载并安装代码静态检查工具。
  *在 Jenkins 工程的构建脚本中，调用代码检查工具生成检查报告文件。

其它的代码静态检查工具集成进 Jenkins 的过程与此类似，如 Checkstyle 和 Android Lint。

Checkstyle

Checkstyle 是一个帮助程序员编写符合某一编码规范的 Java 代码 的开发工具。为它提供编码规范的定义文件和源代码，它自动检查源代码中不符合规范的地方。编码规范的定义文件可以自行配置，比较常用的 Java 代码编码规范如 Sun 代码规范 和 Google Java 代码规范。

在 Jenkins 中集成 Checkstyle 的整体过程与集成 PMD 和 FindBugs 的过程类似。需要为 Checkstyle 安装的插件为 Checkstyle Plug-in，需要为 Jenkins 工程添加的 post-build action 为 Publish Checkstyle analysis results。下载并安装 Checkstyle 工具的方法如下：

$ wget https://excellmedia.dl.sourceforge.net/project/checkstyle/checkstyle/8.8/checkstyle-8.8-bin.tar.gz
$ tar xvf checkstyle-8.8-bin.tar.gz

此外还需要自己定义或下载公开的代码风格定义文件，如 Sun 代码规范 sun_checks.xml 和 Google Java 代码规范 google_checks.xml

执行 Checkstyle 工具生成检查报告的方法如下：

$ java -jar checkstyle-8.8/checkstyle-8.8-all.jar com.puppycrawl.tools.checkstyle.Main -c checkstyle_config/google_checks.xml module/src/main/java -f xml -o checkstyle-result.xml

Checkstyle 工具的 -c 参数用于指定代码风格的定义文件，-f 参数用于指定用于指定输出检查报告文加的格式，-o 参数用于指定输出报告文件的文件名，同时需要为 Checkstyle 指定项目的 Java 源代码路径。上面的命令中 Checkstyle 将输出文件名为 checkstyle-result.xml 格式为 xml 的检查报告。

将 Checkstyle 工具集成进 Python 的工程构建脚本的方法如下：

def run_checkstyle(wrapper_module_name, target_module_name):    if "CHECKSTYLE_ROOT_PATH" not in os.environ.keys():        print("Cannot find Checkstyle")        return    jar_path = os.environ["CHECKSTYLE_ROOT_PATH"] + os.path.sep + "checkstyle-8.8-all.jar"    checkstyle_cmd = "java -jar " + jar_path + " com.puppycrawl.tools.checkstyle.Main"    script_path = __file__    config_file_path = os.path.dirname(script_path) + os.path.sep + "checkstyle_config/google_checks.xml"    checkstyle_cmd = checkstyle_cmd + " -c " + config_file_path    src_dir = " " + wrapper_module_name + os.path.sep + target_module_name + os.path.sep + "src/main/java"    checkstyle_cmd = checkstyle_cmd + src_dir + " -f xml -o checkstyle-result.xml"    print(checkstyle_cmd)    os.system(checkstyle_cmd)

Jenkins 在工程构建结束之后，扫描 Checkstyle 的检查报告，并展示出来：

Android Lint

将 Android Lint 集成进 Jenkins 的过程，与前面的那些 PMD、FindBugs 和 Checkstyle 的过程类似，只是需要安装的 Jenkins 插件为 Android Lint Plugin，需要为 Jenkins 工程添加的 post-build action 为 Publish Android Lint results。

更为简单的是，Android Lint 是 Android Sdk 中的工具，因而无需单独下载安装。对于 Gradle 工程而言，甚至无需单独运行 Android lint 工具，而只需运行 lintDebug 或 lintRelease gradle 任务即可，它们将在模块的 build/reports/lint-results*.xml 处生成 检查报告。

在 Python 的 Jenkins 工程构建脚本中生成 Android Lint 检查报告的方法如下：

def run_android_lint(target_module_name):    lint_task_name = ":%s:lintDebug" % target_module_name    os.system("./gradlew " + lint_task_name)

Android Lint 的检查结果类似于下面这样：

SonaQube Scanner

SonaQube 是一个开源的代码质量分析管理平台，它专注于持续地分析和测量技术方面的质量，从项目组合到方法。通过插件，它可以支持包括 Java，C#，C/C++，PL/SQL，Cobol，JavaScrip，Groovy 等在内的 20 多种编程语言 的代码质量检测与管理。

SonaQube 对代码质量的管理通过 Web 服务 SonaQube 提供，代码质量检测通过 SonaQube Scanner 完成。通常的流程是，SonaQube Scanner 执行代码的静态检查分析，然后将检查的结果传给 SonaQube 服务，SonaQube 服务解析并展示分析结果。

SonaQube Scanner 可以集成进 MSBuild，Maven，Gradle，Ant 等构建系统中，当然也可以集成进 Jenkins 或在命令行上运行。

安装 SonaQube 服务

在 Jenkins 中集成 SonaQube Scanner，分析结果依然需要由 SonaQube 服务来解析与展示，因而首先需要安装 SonaQube 服务。在 SonarQube 的下载页面 选择需要的版本并下载，如 SonarQube 6.7.2 (LTS *) 。

下载完成后，执行如下命令安装并启动 SonaQube 服务：

$ unzip sonarqube-6.7.2.zip

$ sonarqube-6.7.2/bin/linux-x86-64/sonar.sh start

SonarQube 自带数据库和 Web 服务器，因而通过上面简单的两条命令，就可以将 SonaQube 服务运行起来了。默认情况下，SonaQube 服务运行于 9000 端口上：

但需要注意不能以 root 用户启动 SonaQube 服务，否则将启动失败。通过 sonarqube-6.7.2/logs/ 目录下的 ElasticSearch 日志文件 es.log 和 SonaQube 日志文件 sonar.log 可以看到这一点。

为了获得更好的性能和稳定性，可以使用外部的数据库服务， SonaQube 服务对此提供了良好的支持。关于 SonaQube 服务安装配置更详细的过程，可以参考 SonaQube 的官方文档 Installing the Server。

命令行运行 SonaQube Scanner

SonaQube Scanner 可以集成进 MSBuild，Maven，Gradle，Ant 及 Jenkins 等工具中，也可以在命令上独立运行。首先下载并安装 SonaQube Scanner：

$ wget https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.1.0.1141-linux.zip
$ unzip sonar-scanner-cli-3.1.0.1141-linux.zip

然后为要检查的工程编写属性配置文件 sonar-project.properties，如：

java-module.sonar.projectName=Java Module java-module.sonar.language=java # .表示projectBaseDir指定的目录 java-module.sonar.sources=study-project/lib-module-question/src/main/java java-module.sonar.projectBaseDir=study-project/lib-module-question sonar.binaries=classes sonar.projectKey=study-project sonar.sources=study-project/lib-module-question/src/main/java sonar.java.binaries=study-project/lib-module-question/build/intermediates/bundles/debug/classes.jar

上面的配置中，sonar.projectKey 用于指定工程名称，工程名称标识一个工程，SonaQube Scanner 在检查结束之后向 SonaQube 服务发布检查结果，SonaQube 服务以工程为单位展示检查结果。sonar.sources 用于指定要检查的源码的路径。sonar.java.binaries 用于指定编译生成的 jar 文件的路径。

在命令行中，在 sonar-project.properties 文件的相同目录下，执行如下命令：

$ sonar-scanner-3.1.0.1141-linux/bin/sonar-scanner

它将根据 sonar-project.properties 配置文件的内容静态分析源码，并将结果发布给 SonaQube 服务。默认情况下，分析结果将发布给位于 http://localhost:9000 的 SonaQube 服务。但可以通过如下配置项来进行定制：

sonar.host.url=http://localhost:9000 sonar.login=apitoken/username sonar.password=blank/passwd

关于 SonaQube Scanner 执行、配置更详细的信息，可以参考官方文档 Analyzing with SonarQube Scanner、Advanced SonarQube Scanner Usages
和 Analysis Parameters。

在 Jenkins 中集成 SonaQube Scanner
同样需要先为 SonaQube Scanner 安装插件，这次为 SonarQube Scanner for Jenkins。然后以管理员身份登录 Jenkins，并进入 Manage Jenkins > Configure System。向下滚动到 SonarQube configuration 的部分，点击 Add SonarQube，然后按提示输入对应的值，如下图这样：

其中 Name 一栏输入 SonaQube 的名称，名称任意取。Server URL 一栏输入 SonaQube 服务的 Url。Server authentication token 输入用户认证 token，这个 token 是由 SonaQube 服务生成的。

登录 SonaQube 服务（如第一次以 admin（用户名）/admin（密码）登录 SonaQube 服务）之后，点击右上角的用户图标，选择 My Account，打开账户主页，并选择 Security：

在 Generate New Token: 输入框中输入 token 名称，token 名称可任意选择，然后点击 Generate 生成 token。如 SonaQube 服务给出的提示，生成的 token 需要复制出去，这个 token 将无法被再次看到。这个 token 即是前面需要提供给 Jenkins 的 Server authentication token。

然后执行 Jenkins 全局的一些配置，具体而言，是添加 SonarQube Scanner：

以管理员身份登录 Jenkins，然后进入 Manage Jenkins -> Global Tool Configuration。

滚动到 SonarQube Scanner 配置部分，并点击 Add SonarQube Scanner。它基于典型的 Jenkins 工具自动安装。当然也可以选择指向一个已经安装的 SonarQube Scanner 版本（反选 ‘Install automatically’）。

最后是 Jenkins 工程的配置：

打开 Jenkins 工程的配置页面，滚动到 Build 部分。为 Jenkins 工程的构建添加 SonarQube Scanner 构建步骤。配置 SonarQube 分析属性。

也可以指向一个已有的 sonar-project.properties 文件或直接在 Analysis properties 字段设置分析属性，如下图：

然后点击左下角的 Save，保存并结束配置。后面在执行 Jenkins Project 的构建任务时，SonarQube Scanner 将执行，生成分析报告并发送给 SonaQube 服务，报告有 SonaQube 解析并展示。

更多内容请参考 Analyzing with SonarQube Scanner for Jenkins。

国内首个DevOps标准—《研发运营一体化能力成熟度模型》出台了，猜猜您的企业持续交付能到几级？

第一批研发运营一体化（DevOps）能力成熟度模型 第3部分：持续交付评估火热报名中！！

评估报名：牛晓玲

联系方式：010-62300559

邮箱：[e-mail]

培训联系：杨文惠

联系方式：13021086339

邮箱：[e-mail]

更多评估信息，请参见阅读原文