大家好，欢迎来到停止重构的频道。

本期我们详细讨论Jenkins。

随着互联网应用越来越多，系统规模也越来越大，DevOps、CI/CD等概念也被重视起来，持续交付/持续集成/自动化部署等理念也被越来越多的团队接受。

而本期介绍的Jenkins，是目前比较流行的用于自动编译/部署软件项目的系统。

我们按这样顺序展开介绍

1、自动发布的好处

2、Jenkins介绍

3、Jenkins安装

4、Jenkins发布流程配置

自动发布的好处

Jenkins可以简单地理解为一个网站系统，当条件触发时Jenkins就会自动按预设任务进行编译部署。​

例如，Git代码仓库创建了新tag标识后，Jenkins可以自动下载代码，并编译发布到运行的服务器。

那么，自动发布有什么好处呢？

一般认为，可以节省人工编译、部署的时间服务器越多，节省的时间也就越多。

那么，是否只有在项目较大、服务器较多的情况下，才需要自动发布呢？服务器少的话，好像手工打包也花不了多少时间。

不过，我们认为无论项目大小、服务器多少，都应该采用自动发布进行编译、部署。包括开发环境、测试环境、生产环境。

因为在实际发布场景下，不仅仅是替换程序、重启服务这么简单。往往还需要人工修改配置、替换某些文件等。一些服务的启动顺序也是有特殊要求的。

而且如果发布测试时发现了问题则发布行为需要循环多次。

如果是人工发布会有很多人为失误，人为失误是很难排查的，经常是以为几分钟半小时就能发布完成，实际上花了1个通宵或者半天。

在我们看来自动发布，最大的好处并不是单单节省了多服务器的部署时间，而是免去人工编译、部署时可能发生的人为失误，从而节省无意间浪费的成本。

Jenkins的介绍

接下来是Jenkins介绍，简单地说，Jenkins是一个自动发布部署软件的系统，提供管理网站供用户使用。

在管理网站上，用户可以编排自动发布任务，可以实现代码下载-代码编译-文件发送-执行远程命令等场景。

Jenkins除了自身功能，还支持插件如Maven、npm等插件。在管理网站点击安装这些插件，就能快速满足代码编译所需要的环境。

即使有些编译环境无法通过插件完成搭建，也可以在Jenkins运行的服务器上安装对应软件，通过shell指令执行。

发布任务除了在管理网页点击触发，也可以配置远程API触发。

如果是使用Git存储代码的话，可以在Git仓库配置Web hook，在执行一些Git操作时，自动触发对应的Jenkins发布任务。

另外Jenkins也支持分布式部署，多个服务器节点会自动抢占任务。

Jenkins安装

关于Jenkins的安装，可以参考官网说明，官网有详细的安装说明。

我们更推荐使用Docker的方式安装Jenkins，关于Docker的使用说明，可以参考往期《Docker详解》。

Docker方式可以快速部署Jenkins，但比这更重要的是Docker可以将Jenkins隔离起来，也方便日后对Jenkins进行服务器迁移。

虽然Jenkins的插件基本做好了环境隔离，但是很多时候Jenkins的插件不能百分百满足特定软件的编译要求。

也就需要在服务器上手动安装其他软件，这会变相污染服务器环境，可能会对部署在同一服务器的其他服务造成影响。

Jenkins发布流程配置

接下来介绍Jenkins具体发布任务的配置。

新建发布任务一般采用free style方式。

如果是创建与已有发布任务类似的任务，可以直接在创建任务时填写需要复制的任务名称即可快速克隆任务。

配置具体发布任务一般分为4步：下载代码-编译代码-远程部署程序-配置任务自动触发，当然这并不固定，根据实际情况配置即可。

配置：下载代码

第一步下载代码，也就是设置Source Code Management（源码管理）。

Jenkins默认支持Git，如果是SVN等代码库则需要安装额外插件。

值得一提的是，Jenkins默认只支持一个Git仓库的配置，如果需要下载多个Git仓库代码，需要安装Multiple SCMS插件。

下载完这个插件后，源码管理中会出现新的选项（Multiple SCMs），里面可以设置多个Git仓库代码。

下载的代码或者编译生成的文件，可以在运行发布任务后在workspace查看。​

配置：编译代码

第二步编译代码，我们一般是推荐以Shell指令进行编译的。

在Jenkins的服务器上安装相关编译环境后，可以通过Shell指令编译软件。

发布任务运行过程中，Jenkins会捕获所有终端log，以方便用户记录、排查错误。

当然，Jenkins官方更推荐使用插件完成编译。Jenkins插件更加安全，一般也做好了多版本切换、环境隔离等工作。

但是，我们还是更喜欢Shell指令编译，Shell指令更加灵活，而且Jenkins插件大多没有详细的使用说明。

对于一些特别复杂的代码编译，例如自研框架等，或者希望Jenkins可以大杂烩地编译多种软件的话，则推荐采用Jenkins调用docker的方式进行编译。

就是将单个编译环境打包成docker镜像，Jenkins在编译时采用此镜像进行编译，但是配置起来有些麻烦，特别是docker运行的Jenkins中再内嵌docker，将在下一期重点展开。

顺便一提，使用图形软件界面编译虽然可以实现，但是特别麻烦，也不实用，无法捕获编译错误，这里不作展开。

配置：远程部署

第三步远程部署程序。

这一步骤同样可以采用Shell指令完成，可以使用scp、ssh完成文件发送、远程指令执行。

​如果担心有密码泄漏等问题，可以使用Jenkins的Publish Over SSH插件完成这一步骤。

下载完Publish Over SSH插件后，需要先在全局的系统配置中添加好远程服务器。

完成以上准备工作后，在发布任务配置中就可以选择对应远程服务器，配置需要发送的文件、及需要远程执行的shell指令。

当然，一些安全等级比较高的生产环境，一般都做了严格的网络隔离。

如果不允许自动远程发送文件、部署程序的话，则可能需要人工下载文件进行手工部署了。

可以在具体发布任务的workspace中找到需要的文件并进行下载。

​配置：任务自动触发

第四步是配置任务自动触发。

如果是比较重要的运行环境，如生产环境，还是手动点击触发任务比较好。

如果是开发环境、测试环境，则更推荐自动触发任务。

比如新代码上传Git仓库后，自动触发任务，或者Git仓库打上新的tag标签后，自动触发任务。

配置任务自动触发，需要在具体发布任务配置中获取对应的API地址，其中TOKEN_NAME需要替换成设置的Token，JENKINS_URL需要替换成实际的Jenkins的IP地址。

但是这个API通常是调用不通的，除非配置了允许不登录即可使用Jenkins，所以还需要在API地址中设置用户名和用户token。

用户token需要手动创建，打开用户设置在API Token中新建token。新建token在关闭页面后，将不再显示。

完整的API如图所示。

获取到完整的API后，即可在具体的Git仓库的WebHook中进行配置。

Git仓库的WebHook设置中，可以勾选触发事件，如Push事件那么每次新代码上传时，就会自动触发Jenkins发布任务。

总结

本期主要介绍了Jenkins的基本使用方法，当然Jenkins还有很多功能。

如编译历史、历史归档、自动升级、多节点执行任务、账号权限等等功能，这里不作展开。

另外，Jenkins实质上是一个很完整的分布式云计算任务系统。

它甚至可以作为业务系统的一部分，以实现复杂耗时的云计算任务，感兴趣的朋友可以深入了解一下。