Jenkins自动化打包部署项目落地实践_jenkins2.4版本支持的jdk

---

I 背景

1. 众多相互依赖的微服务打包需严格保证打包顺序，前置服务未打包完成的情况下，后置服务启动打包即容易出现漏打；或者前置服务已打包，后置服务部分打包的情况即出现少打。依靠每个开发人员自行甄别控制，一方面过于繁琐，另一方面也增加新员工培训成本。
2. 当前的测试环境打包即使在提供了固定的打包机、多人多地点同时协同开发的情况下，整个打包过程过于封闭不透明，同时也存在打包机资源挤退、抢占或重复打包的情况。
3. 打包机打包方式过于原始，依然采用的是IDEA打包，对于多工程服务情况下，同时打开过多的IDEA数量对打包机的资源消耗过大，虽然能直观的看到代码以及修订过程，整体的打包体验弊大于利。

基于以上现状，在项目里推出Jenkins自动化打包部署方案，带来以下改观：

---

II Jenkins安装部署

2.1.Jenkins官网下载安装包

最新版本¹：

历史版本¹：

对应版本与JDK支持关系：

2.2.Jenkins安装

此处以【2.426.1 LTS Windows】版本为例

2.2.1 启动Jenkins流程

第一次启动

Win+R 打开cmd窗口
java -Xms4096m -Xmx8192m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=8192m -DJENKINS_HOME=D:\SOFT\jenkins2.426.1-dev\jenkins -jar D:\SOFT\jenkins2.426.1-dev\jenkins.war --httpPort=8090
1
2

-DJENKINS_HOME 该参数指定Jenkins工作目录，打包工程会存放该目录
--httpPort 指定启动端口（默认为：8080）
1
2

启动成功后终端会打印出初始密码

访问Jenkins Web端（http://localhost:8090 端口如果未指定默认用8080）


初始密码也可通过配置文件中获取，路径为：
%JENKINS_HOME\secrets\initialAdminPassword

安装插件，可选择按推荐的安装也可选择自定义安装，后续也可根据需要在插件中心中安装插件


注：等待所有插件安装结束后会自动跳转页面，若安装插件失败，多半是由于插件中心地址访问超时，可修改为国内地址，重新安装即可

--修改插件中心地址
--配置文件目录：%JENKINS_HOME\hudson.model.UpdateCenter.xml
<url>http://mirror.xmission.com/jenkins/updates/update-center.json</url>
1
2
3

创建管理员用户

实例配置

配置好之后的jenkins页面

2.2.2 安装个性化插件

大家打开基础版的Jenkins后就会发现，虽然Jenkins安装成功了，但似乎还不太满足项目构建的需要，当然了Jenkins提供了很多个性化的插件，我们可以根据需要自由搭配来满足不同场景的构建需求
比如：我想新建一个Maven的构建，基础版是没有该选项的，那么我们可以在插件中心去安装该类插件

打开插件中心



此处罗列常用的功能插件

---

III 项目打包配置

3.1 工具配置

Maven配置
菜单路径：Dashboard\Manage Jenkins\Tools

JDK配置
菜单路径：Dashboard\Manage Jenkins\Tools

SSH配置
菜单路径：Dashboard\Manage Jenkins\System（该配置有所不同，在System下）

3.2 新增构建流程

新增Maven构建项目

指定JDK参数

修改并发构建参数
修改后在上游项目未构建完成时，如果主动触发构建下游项目会阻止构建放到等待队列里，避免做无用构建

添加Git信息

去掉POM项目依赖检查
此处去掉该检查的意义在于，如果勾选了该选项，Jenkins会自动根据pom文件识别出项目上下级依赖关系，会在上游项目构建完成后自动触发下游项目，去掉勾选后自行指定依赖，让Jenkins完全按照配置来打包

指定pom文件路径
默认在该工程目录的下一级，如果需要指定到更深层次pom，只需要添加工程目录下的路径即可

添加构建后windows执行脚本
由于我们已有部署平台，通过部署平台上传部署包，同时会更新数据库信息，直接上传到服务器目录并不会做登记，所以我们统一将发布物复制到固定目录，Jenkins可直接执行Windows batch command

添加构建后SSH上传
非必须，该处为演示

添加构建后触发其他项目
该处可指定上下游关系，上游项目构建成功后会触发下游项目打包

配置远程触发构建
该功能可以配合GitLab的Webhooks事件使用，在代码Push、Merge等场景下执行远程调用脚本，自动触发Jenkins构建

---

IV 操作流程

---

V 使用总结

项目内已经持续使用了一个多月，目前两套频繁使用的测试环境都是通过Jenkins来构建，在满足使用的前提下也带来很多便捷，最主要的是开发人员习惯的改变，当然了凡事都有两面性，对于频繁打版的测试环境，也暴露出自动化构建的一些短板。

• 亮点

1. 自动化构建的最大亮点，避免了繁琐的人工操作，配置好规则后Jenkins即会按照预设的方向运行
2. 配置好各工程依赖规则后，Jenkins会进行构建校验，确保前置工程已构建完的情况下构建下游项目，避免重复无用的构建
3. 整个构建过程对项目组内开发人员完全透明化，哪个工程什么时候构建了，成功还是失败，构建日志能查看失败原因，变更记录能查看本次构建的代码修订记录，工作空间里能查看构建的工程，甚至某个工程的某个构建是由于依赖自动触发还是哪个用户手动触发构建等等信息
4. 支持视图化操作，提取常用工程，快捷操作

• 短板

1. 构建透明化的同时带来的问题就是代码不透明，Jenkins是自动拉取Git代码，调用Maven打包，在频繁改动代码的测试环境很容易出现某个开发人员提交的代码影响了构建，离开了编译器的帮助的话不容易去定位问题，即使在Jenkins控制台输出了部分日志信息的情况下，出现问题后还得远程到Jenkins所在的服务器去排查代码，或者开发人员本地跑一遍构建
2. 同以前的打包方式相比，Jenkins依然需要一个打包机服务器资源，同时为了保证构建的运行流畅，对服务器的内存、磁盘配置也有一定要求

亮点也好，短板也罢，Jenkins的设计初衷当然并非为了解决某一个项目的问题，亮点应该就是用对了场景，短板也应该还有其他的解决方案，局限我们的不是工具，而是思维。

---

1. 选择LTS长期支持版本 ↩︎ ↩︎