ci工程 java_Jenkins在Java web项目CI/CD中的简单应用

JenkinsJenkins is a self-contained, open source automation server which can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software.主要介绍使用Jenkins来达到持续集成持续交付/持续部署(CICD)的一些方案和选择，不涉及Jenkins的深入研究。

实现CI/CD的方式有很多种，本文介绍的只是我这几天一些粗略的摸索，仅供大家参考。

一、安装Jenkins的安装方式有很多选择，这里不做详细讨论，我这次采用了比较熟悉的部署WAR包的方式，将其部署到tomcat上来运行。

部署完成之后访问相应地址即可，这是会提示新建用户，大家按照指引一步一步完成即可，不做赘述。

二、新建任务Jenkins部署完成之后，接下来便要进入正题了，新建一项任务，已达到CICD的目的。

首页左侧菜单按选择新建任务-》输入任务名称-》构建一个自由风格的软件项目-》确定(这里我已经创建过一个名为test的项目了)

点击确定后进入了该项目的配置页面，先总览所有的配置项，共有六项：General，源码管理，构建触发器，构建环境，构建，构建后操作.从字面意思上不难理解。General，一些通用的信息，本次不做重点；

源码管理，构建的来源，git，svn，亦或是其他一些源码管理服务；

构建触发器，以何种规则自动触发源码的构建(持续构建)，若该项不做任何配置，则只能手动触发；

构建环境，本次也未做关键性修改；

构建，以何种方式构建，maven， gradle， 亦或是其他；

构建后操作，成功构建之后的一些操作，持续交付/持续部署的操作主要放到这一块。

接下来分别较少这几项配置，以及用到的插件，已完成CI/CD的目标。

1. General本次并没有做一些关键的修改

2. 源码管理只说明git的一些相关配置，其他的源码管理服务同理

Repository URL： git上的源码地址

Credentials： 用户名/密码

Branch Specifier：指定需要构建的分支

上边这些做完后其实基本上已经可以了，之所以修改Advanced clone behaiours，是防止第一次构建时拉取源码超时，默认超时时间为10minutes，多次构建失败后，我把此处修改为了20minutes，如果依旧超时，可延长此处时间，或检查网络(点击Additional Behaviours旁边的add，选择Advanced clone behaiours)Shallow clone，Shallow clone depth：浅拷贝，节省拷贝时间和磁盘空间

3. 构建触发器实现触发构建的方式主要有定时触发、web hook触发，这些触发方式可以单独使用，也可以组合使用。

3.1 定时触发Build periodically： 周期性构建

Poll SCM： 周期性检测，若源码有变化则构建

定时构建部署，可控制频率

3.2 Gitlab Hook插件

web hook触发主要介绍gitlab hook插件，接下来我们先保存已经完成的配置，回到首页，下载所需插件。

可选插件中搜索gitlab，勾选列表中的GitLab Plugin和Gitlab Hook Plugin, 选择直接安装。待安装完成后回到首页，点击右边刚刚我们创建的任务，然后点击配置回到我们之前的配置页面。

此时发现构建触发器中多了个选项：Build when a change is pushed to GitLab. GitLab CI Service URL: http://172.16.192.142:9081/jenkins/project/test，如果仍然没有，尝试重启Jenkins之后查看。

图中红框上边为Gitlab Web Hook处需要添加的URL，若Jenkins设置了不允许匿名用户执行构建操作，则需要在Gitlab安全令牌处添加第二个红圈处的Secret token。Gitlab处需要增加的配置(设置-》集成，注意登录账户需要有相应权限)

随时提交，随时构建，快速相应开发人员的操作，但需要开发人员提交代码的时候确保提交可用，多次commit一次push，除非紧急需要尽量在午休时间，早上上班前，晚上下班后push代码

4. 构建环境没有关键配置的修改，其中Color ANSI Console Output为下载的插件AnsiColor，可以使日志输出带有颜色，详情可查看Jenkins 的输出日志也可以变得色色的

5. 构建构建部分主要采用了maven构建，确保部署Jenkins的机器已经配置好了maven环境，maven的配置不做赘述。

6. 构建后操作使用maven构建打包完成后，与pom.xml同级的target目录下会生成一个war包(取决于pom.xml中的配置，对pom.xml的配置不做描述)，接下来我们要做的就是将生成的war包部署到中间件或容器中，下面主要介绍两个插件，可以根据实际情况有选择的使用，使用之前首先需要参考之前介绍的步骤下载相应插件。

6.1 Deploy to Container插件达到效果：构建前需保证目标中间件正常启动，每次Jenkins构建时会把指定的war包自动部署到指定的服务器上的context path中，如果目标服务已存在，首先undeploy目标服务，再把新的war包redeloy上去，已完成自动部署的功能。

仅支持GlassFish,JBoss,Tomcat

增加构建后操作步骤中选择Deploy war/ear to a container

WAR/EAR files中填上所需要部署的程序包，支持**/*.war的形式

Context path配置程序相对于中间件环境的发布路径

本文中Containers我选择了Tomcat 7.x，Credentials需要在tomcat里配置上，Tomcat URL即环境的基础地址在tomcat中添加授权用户：修改conf/tomcat-users.xml

只是做上边这些配置的话，你会发现Jenkins的自动部署仅支持第一次，已有旧版应用运行时，自动部署会报undeploy失败，原因是在应用运行时，tomcat会对应用的资源进行锁定，导致无法覆盖更新，这时需修改tomcat的另一项配置：conf/context.xml(详情可查看Tomcat中antiResourceLocking和antiJARLocking的作用)

6.2 Publish Over SSH插件通过SSH操作目标服务，从而传输文件，执行命令已达到目的

更灵活，支持各种中间件服务器

首先在系统设置中配置上所需连接的远程服务器，配置上相关配置，其中Remote Directory是访问服务器的基础路径，之后步骤能用到

然后回到任务配置继续配置构建后操作一块

Remote directory 远程服务器文件夹，空即为默认的上边步骤配置的路径，如果此处不为空，即为相对路径Remove prefix 去除前置路径

Exec command 执行脚本，此处的脚本比较简单，调用目标中间件的停止与启动

需要注意的是执行脚本的时候有个坑，读取不到系统的环境变量，原因是此处执行脚本的方式为non-interactive + non-login shell，不会读取/etc/profile中的配置，此处的解决方案是采用bash执行命令，由于bash恒执行BASH_ENV中的变量，因此需要把/etc/profie赋值到BASH_ENV中，详细解决思路参考链接

三、其他至此已经完成了从开发人员push代码到应用构建、部署等相关操作的基本自动流程，具体细节部分还需要继续深入研究探索

遗留问题：Jenkins构建的时候控制台乱码解决之后，Jenkins启动的tomcat发生乱码

自动构建部署的时候，Jenkins调用命令启动StartTAS.sh的时候会一直监听启动日志，直到超时才断开链接，这时候因超时而导致本次构建为黄灯，即不稳定的构建