共计 3669 个字符，预计需要花费 10 分钟才能阅读完成。
Jenkins
Jenkins 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：周期性检测，若源码有变化则构建
图中为每六小时检测一次
搞清楚 jenkins 中“Poll SCM”和“Build periodically”的啥意思
定时构建部署，可控制频率
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 代码
参考资料:Gitlab 利用 Webhook 实现 Push 代码后的 jenkins 自动构建
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
<role rolename=”manager-script”/>
<user username=”caozeal” password=”******” roles=”manager-script”/>
只是做上边这些配置的话，你会发现 Jenkins 的自动部署仅支持第一次，已有旧版应用运行时，自动部署会报 undeploy 失败，原因是在应用运行时，tomcat 会对应用的资源进行锁定，导致无法覆盖更新，这时需修改 tomcat 的另一项配置：conf/context.xml（详情可查看 Tomcat 中 antiResourceLocking 和 antiJARLocking 的作用）
<Context antiJARLocking=”true” antiResourceLocking=”true”>
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 中，详细解决思路参考链接
ssh 连接远程主机执行脚本的环境变量问题
转：深入了解 bash 与 sh 的区别
三、其他
至此已经完成了从开发人员 push 代码到应用构建、部署等相关操作的基本自动流程，具体细节部分还需要继续深入研究探索
遗留问题：
Jenkins 构建的时候控制台乱码
参考 Jenkins 控制台中文输出乱码解决方法处理
解决之后，Jenkins 启动的 tomcat 发生乱码
自动构建部署的时候，Jenkins 调用命令启动 StartTAS.sh 的时候会一直监听启动日志，直到超时才断开链接，这时候因超时而导致本次构建为黄灯，即不稳定的构建
