用 jenkins 来提高部署测试的效率

Posted 2021-04-07 古时的风筝

开发一时爽，集成测试、集成部署什么的最麻烦了，有没有，尤其是项目开发完成，QA 测试阶段，每天上 N 个版本。

累不累？真累啊。

烦不烦？真烦啊。

怎么办，用 Jenkins 吧。

Jenkins 是非常流行的开源的持续集成工具。它提供了众多的插件，可以使项目构建、部署、发布自动化实现，并且部署简单，使用方便。

Jenkins 有众多插件支持，并且可以灵活的和自定义脚本做集成，无论是前端项目还是后端项目，无论是哪种语言实现，只要是可以部署到服务器上的，都可以用 Jenkins 来简化我们的工作，节省时间，提高效率。

这里简单记录了一下 Jenkins 的安装配置，以及通过 Jenkins 快速简单的构建发布 Maven Java 项目。还没有使用的开发朋友们，赶快用起来吧。

安装和配置

1、到官网 https://jenkins.io/download/ 下载 war 包，war包自带Jetty服务器 ，只需运行命令：

java -jar jenkins.war  --httpPort=10000

就可以在 10000 端口启动 jenkins 。

2、第一次启动的时候，会生成一个随机密码，如下：

3、在浏览器访问 10000 端口，出现如下界面，输入 Administrator password 密码，即上面的随机密码

4、"Continue" 之后，开始初始化，稍等片刻，出现如下界面，默认选择 “Install Suggested Plugins”即可。

5、开始默认插件的安装，需要等待一段时间。安装完成后，输入用户名和密码等信息即可完成初始配置。

6、进入“全局工具配置”页面，配置好 JDK、Git、Maven、Maven Configuration 。建议全部手工安装，然后手动配置。

7、进入插件管理，搜索 Maven Integration plugin ，并安装，主要是为了构建 maven 项目。

创建持续集成项目

进入首页，点击新建，并选择"构建一个 Maven 项目"。

点击确定之后，进入项目配置页面,接下来对项目做完整配置，制定个性化的集成方案。

通用配置

填写项目名称、描述等信息

源码管理

以 Git 为例，可以是 GitHub 、GitLab 等代码托管系统。

2、添加一个证书，这里是 https 协议，增加一个账号密码类型的证书

3、 然后选择一个分支，默认是 master 分支。

构建触发器

项目除了可以手动构建之外，还可以设置触发器，jenkins 提供了几种比较有用的触发器

Build whenever a SNAPSHOT dependency is built

当 pom.xml 中的<dependency>发生了变化时，就会触发一次构建，也就是修改了maven 依赖包，比如引入了新的包、删除了之前的包、更改了包版本等。

触发远程构建

如果选择使用远程构建触发，在身份验证令牌这里设置好一个 token 值，可以自己随意定，之后访问 JENKINS_URL/job/maven-svn/build?token=TOKEN_NAME 或者 /buildWithParameters?token=TOKEN_NAME，例如我这里就可以访问 http://127.0.0.1:10000/job/maven-svn/build?token=my-jenkins-token

Build after other projects are built

当一个其他项目构建之后触发构建当前项目，可以选择是其他项目构建成功、不稳定或者失败之后触发。

Build periodically

设置一个 Cron 表达式，例如每天固定时间、每隔几个小时、每周几等等，不管源代码是否发生了变化，都执行构建任务。如图，是每天凌晨 3 点执行。具体 Cron 参看说明即可。

GitHub hook trigger for GITScm polling

GitHub 专用的触发器设置，需要配合 github Webhooks 使用。

Poll SCM

区别于 Build periodically ，同样是设置一个 Cron 表达式，不同的是，会检查源代码是否发生了变化，如果有变化才执行构建，否则不执行。

构建环境

一般不需要更改。

Pre Steps

构建之前的动作，比如构建前执行一段 shell 脚本。一般不用。

Build

正式构建，因为这里是创建的 maven 项目，所以主要就是配置 Root POM 和 maven 命令。

如图，意思是主 pom 文件名称为 pom.xml ,需要执行的 maven 命令是 clean package ,即先清理，再打包。

点击“高级”可以设置更多的 maven 配置，具体没有用过。

通知配置

系统自带的邮件配置

1、进入「系统管理」- 「系统设置」。

4、勾选“通过发送测试邮件测试配置”，填写需要发送测试的邮箱，可以测试一下配置是否成功。

5、回到项目配置页面，勾选 “E-mail Notification”，填写通知人列表（多个邮箱用空格分隔）。

到此配置完成，但是只能在构建失败时发送邮件通知，功能过于简单。下面介绍扩展插件的方式。

2、进入 「系统管理」- 「系统设置」，找到 “Extended E-mail Notification”并打开高级设置，设置好 SMTP server、勾选 Use SMTP Authentication、填写邮件发送方账号和密码、勾选 Use SSL。这些信息是必须的。另外，可以填写默认通知列表、默认内容类型格式、默认邮件主题、默认邮件内容等配置。

4、添加触发器，可以在构建前、构建成功、构建失败等多种状态下发送邮件通知。这里配置了失败和成功两种状态触发器，并且每个触发器都可独立配置通知人、邮件主题、内容等，如果配置了会覆盖上一步的默认配置。这里要注意的是，通知人默认是 Developers ,需要改成 Recipient List。

5、保存配置，并构建项目，可以受到如下格式的邮件通知

集成钉钉群通知

1、首先在钉钉客户端新建一个通知群，点击聊天机器人。

2、选择一个自定义机器人。

4、到「系统管理」-「管理插件」下安装 Dingding[钉钉] Plugin 插件。

6、最后构建项目，将会收到如下通知。

部署发布

项目构建完成，对于整个集成部署来说，只是完成了百分之五十。剩下就是部署发布了，到了发布这一环节就需要对接其他功能或系统了。

Post Steps

构建完成之后执行的动作，可以选择只在构建成功后、构建成功或不稳定时、不管构建结果如何三种时机。

例如在构建成功后，可以执行一段 shell 脚本，由此，我们可以发挥想象，通过这一段 shell 脚本能做哪些操作：

1、比如通过脚本调用一个 API 接口，通过然后 API 主动下载构建好的包；

2、比如通过脚本主动推送打好的包到远程待部署服务器

之后，如果是简单的部署环境，例如之后两三台服务器，可以在待部署服务器上用脚本实现。

如果是机器比较多的情况，可以接入 saltstack 等运维工具。

如果是 docker 场景下，另有其他的实现方式。

部署实例

下面结合 Publish Over SSH 和 shell 脚本完成远程部署 war 包到远程 tomcat

1、到“系统管理”--->“管理插件”，在可选插件中搜索 Publish Over SSH，完成安装。

2、到“系统管理”--->“系统设置”中，找到 Publish over SSH 设置区域，配置 ssh server 配置

Passphrase：如果是秘钥登录，在使用ssh-key 创建秘钥的过程中会提示输入密码，如果输入了，这里就填写那个密码

Path to key：秘钥文件（私钥）在 jenkins 服务器的位置

SSH Server Name：服务器名称，随意填写，帮助标示服务器

Hostname：需要连接 ssh 服务器 IP

Username：用户名

Remote Directory：远程目录，即发送的文件会保存到这个目录，这里就是 war 包要临时保存的位置

Use password authentication, or use a different key：使用密码或其他的key

Passphrase / Password : 密码或其他秘钥文件创建时所用的密码，这里使用的是用户名密码方式。

3、配置好之后，点击 “Test Configuration” 按钮，如果提示 success 则表示配置成功，保存配置。

4、回到项目配置页面，在“增加构建后操作步骤”中选择 “Send build artifacts over SSH”

可以配置多个SSH Server，就是说可以把构建出来的包部署到台服务器上。

Name ：选择刚刚配置的那个部署服务器

Transfers: 传输器，可以配置多个 Transfer Set，也就是说如果一台服务器上有多个 tomcat，可以通过不同的Transfer Set 传输，并且执行特定的命令。

Source files:源文件，即构建好的 war 包，这里是选择所有的 war 包。

Remove prefix : 要移除的路径前缀，如果 Source files 是 /target/xxx.war ，这里填写 /target 就可以在发送到部署服务器的时候，在 Remote directory 目录不创建 target 子目录，而直接将 xxx.war 发送到 Remote directory 根目录。注意：如果是多个 war 包，Remove prefix 必须是这几个 war 包所在路径共有的路径前缀（即以 Remove prefix 开始的目录）

Remote directory：部署服务器存放 war 包的目录，如果为空，则默认继承之前配置的路径

Exec command: 在部署服务器上执行的部署脚本，脚本要放在部署服务器上面。

5、根据具体的环境配置等信息，写一个shell 脚本文件，即上面的 deploy.sh 。脚本要完成的内容为：先查到要部署的那个tomcat 实例的 pid ,然后 kill 掉它，接着将之前的 war 包备份一下，然后将刚刚发送过去的 war 包复制到 tomcat 的 webapps 目录下，最后调用 bin 目录下的 ./startup.sh 脚本启动 tomcat 。

以上只是一个简单配置和部署过程，用与开发测试集成部署场景或者服务器很少的情况下。

也可以通过点击{阅读原文}到我的博客上查看。