最近花了一段时间研究 jenkins 这个工具。所以写下这篇文章，算是当做记录吧！
Jenkins 是一个开源的、提供友好操作界面的持续集成 (CI) 工具，起源于 Hudson（Hudson 是商用的），主要用于持续、自动的构建 / 测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解释）。Jenkins 用 Java 语言编写，可在 Tomcat 等流行的 servlet 容器中运行，也可独立运行。通常与版本管理工具(SCM)、构建工具结合使用。常用的版本控制工具有 SVN、GIT，构建工具有 Maven、Ant、Gradle。
CI(Continuous integration，中文意思是持续集成) 是一种软件开发时间。持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。借用网络图片对 CI 加以理解。
CI
CD(Continuous Delivery， 中文意思持续交付)是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境 (类生产环境) 中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境。下图反应的是 CI/CD 的大概工作模式。
CI/CD
Jenkins 是一个强大的 CI 工具，虽然本身使用 Java 开发，但也能用来做其他语言开发的项目 CI。下面讲解如何使用 Jenkins 创建一个构建任务。
登录 Jenkins， 点击左侧的新建，创建新的构建任务。
跳转到如下界面。任务名称可以自行设定，但需要全局唯一。输入名称后选择构建一个自由风格的软件项目 (其他选项不作介绍)。并点击下方的确定按钮即创建了一个构建任务。之后会自动跳转到该 job 的配置页面。
新建自由风格的软件项目
下图是构建任务设置界面，可以看到上方的几个选项“General”, “源码管理”， “构建触发器”，”构建环境”， “构建”， “构建后操作”。下面逐一介绍。
1.General
General 是构建任务的一些基本配置。名称，描述之类的。
General
项目名称:是刚才创建构建任务步骤设置的，当然在这里也可以更改。
描述:对构建任务的描述。
丢弃旧的构建： 服务器资源是有限的，有时候保存了太多的历史构建，会导致 Jenkins 速度变慢，并且服务器硬盘资源也会被占满。当然下方的 “保持构建天数” 和 保持构建的最大个数是可以自定义的，需要根据实际情况确定一个合理的值。
其他几个选项在这里不做介绍，有兴趣的可以查看 Jenkins”帮助信息”， 会有一个大概的介绍。不过这些 “帮助信息” 都是英文的。
点击右方的这些 “问号” 查看 “帮助信息”
2. 源码管理
源码管理就是配置你代码的存放位置。
源码管理
Git: 支持主流的 github 和 gitlab 代码仓库。因我们的研发团队使用的是 gitlab，所以下面我只会对该项进行介绍。
Repository URL：仓库地址
Credentials：凭证。可以使用 HTTP 方式的用户名密码，也可以是 RSA 文件。 但要通过后面的 “ADD” 按钮添加凭证。
Branches to build：构建的分支。*/master 表示 master 分支，也可以设置为其他分支。
源码浏览器：你所使用的代码仓库管理工具，如 github, gitlab.
URL：填入上方的仓库地址即可。
Version: 8.7 这个是我们 gitlab 服务器的版本。
Subversion： 就是 SVN，这里不作介绍。
3. 构建触发器
构建触发器，顾名思义，就是构建任务的触发器。
触发远程构建 (例如，使用脚本): 该选项会提供一个接口，可以用来在代码层面触发构建。这里不做介绍，后期可能会用到。
Build after other projects are built： 该选项意思是 “在其他 projects 构建后构建”。这里不作介绍，后期可能会用到该选项。
Build periodically： 周期性的构建。很好理解，就是每隔一段时间进行构建。日程表类似 linux crontab 书写格式。如下图的设置，表示每隔 30 分钟进行一次构建。
周期构建
Build when a change is pushed to GitLab： 当有更改 push 到 gitlab 代码仓库，即触发构建。后面会有一个触发构建的地址，一般被称为 webhooks。需要将这个地址配置到 gitlab 中，webhooks 如何配置后面介绍。这个是常用的构建触发器。
Poll SCM： 该选项是配合上面这个选项使用的。当代码仓库发生改动，jenkins 并不知道。需要配置这个选项，周期性的去检查代码仓库是否发生改动。
十分钟检查一次
构建环境就是构建之前的一些准备工作，如指定构建工具 (在这里我使用 ant)。
构建环境中的构建工具
With Ant： 选择这个工具，并指定 ant 版本和 jdk 版本。这两个工具的版本我都事先在服务器上安装，并且在 jenkins 全局工具中配置好了。
其他选项不作介绍，同样可以查看 “帮助信息” 获得使用帮助。
选择下方的增加构建步骤。
增加构建步骤
可以选择的项很多。这里就介绍 “Invoke Ant” 和 “Execute shell”.
Eexcute shell： 执行 shell 命令，该工具是针对 linux 环境的，windows 环境也有对应的工 具 “Execute Windows batch command”。 在构建之前，可能我们需要执行一些命令，比如压缩包的解压之类的。为了演示，我就简单的执行 “echo $RANDOM” 这样的 linux shell 下生产随机数命令。
Invoke Ant：Ant 是一款 java 项目构建工具，当然也能用来构建 php。
Ant Version： 选择 Ant 版本。这个 ant 版本是安装在 jenkins 服务器上的版本，并且需要在 jenkins”系统工具” 中设置好。
Targets：要执行的操作，一行一个操作任务。以上图为例，build 是构建，tar 是打包。
Build File: 是 Ant 构建的配置文件，如果不指定，则是在项目路径下的 workspace 目录中的 build.xml。build.xml 文件具体怎么配置，后面再细讲。
properties: 设定一些变量，这些变量可以在 build.xml 中被引用。
Send files or execute commands over SSH： 发送文件到远程主机或执行命令 (脚本)
Name: SSH Server 的名称。SSH Server 可以在 jenkins - 系统设置中配置。
source files: 需要发送给远程主机的源文件。
Remove prefix: 移除前面的路径。如果不设置这个参数，则远程主机会自动创建构建源 source files 包含的那个路径。
Remote directory: 远程主机目录。
Exec command：在远程主机上执行的命令，或者执行的脚本。
构建后操作，就是对 project 构建完成后的一些后续操作，比如生成相应的代码测试报告。
邮件通知
Publish Clover PHP Coverage Report： 发布代码覆盖率 xml 格式的文件报告。路径会在 “build.xml” 文件中定义
Publish HTML reports：发布代码覆盖率的 HTML 报告。
Report Crap: 发布 crap 报告。
E-mail Notification: 邮件通知，构建完成后发邮件到指定的邮箱。
以上配置完成后，点击保存。
SSH Server 配置
登录 jenkins — 系统管理 — 系统设置
配置请看下图
SSH SERVER
SSH Servers: 由于 jenkins 服务器公钥文件我已经配置好，所以之后新增 SSH Servers 只需要配置这一项即可。
Name： 自定义，需要全局唯一。
HostName: 主机名，直接用 ip 地址即可。
Username: 新增 Server 的用户名，这里配置的是 root。
Remote Directory: 远程目录。jenkins 服务器发送文件给新增的 server 默认是在这个目录。
Ant 配置文件 “build.xml”
接下来讲解 Ant 构建配置文件 “build.xml”。 之所以是 build.xml 这是因为官方惯例。就好比任何编程语言的入门都会是打印 “Hello world”. 你也可以用其他名称代替 “build.xml” .
下面针对配置文件 “build.xml” 关键配置进行说明。
project name 就是项目名称，和 jenkins 所创建的对应。
target name=”build” 就是构建的名称，和 jenkins 构建步骤 那里的 targets 对应。depends 指明构建需要进行的一些操作。
property 用来设置变量。
fileset 这一行指明了一个文件夹，用 include 来指明需要包含的文件，exclude 指明不包含的文件，”tar” 即是打包这个文件夹中匹配到的文件。
下面的这些 target 都是一些实际的操作步骤，比如 make_runtime 这个 “target” 就是创建了一些目录。phpcs 就是利用 PHP_CodeSniffer 这个工具 对 PHP 代码规范与质量检查工具。
最后这个 target “tar” 就是打包文件。因为上面的 build 并没有包含这个 target，所以默认情况下，执行 build 是不会打包文件的，所以在 jenkins project 配置界面，Ant 构建那一步的 targets，我们才会有 “build” 和 “tar” 这两个 targets。如果 build.xml 中 “build” 这个 target depends 中已经包含 “tar” , 就不需要在 jenkins 中增加 “tar” 了。
其他一些 target 都是利用一些工具对 php 代码的操作，比如 phpunit 是进行 php 单元测试。这一些方面我没有深入的研究，只是进行了一些简单的配置，毕竟不是这方面的专业人士。
配置 Gitlab webhooks
在 gitlab 的 project 页面 打开settings，再打开 web hooks 。点击“ADD WEB HOOK” 添加 webhook。把之前 jenkins 配置中的那个 url 添加到这里，添加完成后，点击“TEST HOOK”进行测试，如果显示 SUCCESS 则表示添加成功。
配置 phpunit.xml
phpunit.xml 是 phpunit 这个工具用来单元测试所需要的配置文件。这个文件的名称同样也是可以自定义的，但是要在 “build.xml” 中配置好名字就行。默认情况下，用 “phpunit.xml”, 则不需要在 “build.xml” 中配置文件名。
build.xml 中 phpunit 配置
fileset dir 指定单元测试文件所在路径，include 指定包含哪些文件，支持通配符匹配。当然也可以用 exclude 关键字指定不包含的文件。
第一次配置好 jenkins project 之后，会自动触发一次构建。此后，每当有 commit 提交到 master 分支（前面设置的是 master 分支，也可以设置为其他分支），就会触发一次构建。当然也可以在 project 页面手动触发构建。点击左边的 “立即构建” 手动触发构建。
手动触发构建
构建状态
Successful 蓝色：构建完成，并且被认为是稳定的。
Unstable 黄色：构建完成，但被认为是不稳定的。
Failed 红色：构建失败。
Disable 灰色：构建已禁用
构建稳定性
构建稳定性用天气表示：晴、晴转多云、多云、小雨、雷阵雨。天气越好表示构建越稳定，反之亦然。
构建历史界面
console output： 输出构建的日志信息
由于 jenkins 默认的权限管理体系不支持用户组或角色的配置，因此需要安装第三发插件来支持角色的配置，本文将使用 Role Strategy Plugin。基于这个插件的权限管理设置请参考这篇文章:http://blog.csdn.net/russ44/article/details/52276222，这里不作详细介绍。
至此，就可以用 jenkins 周而复始的进行 CI 了，当然 jenkins 是一个强大的工具，功能绝不仅仅是以上这些，其他方面要是以后用到，我会更新到这篇文章中。有疑问欢迎在下方留言。
最后，放上一张 Jenkins 的思维导图
若有收获，就点个赞吧
0 人点赞
