第42讲：JenkinJob管理

本课时我们开始进入 Jenkins Job 管理的学习。我们在上一课时已经搭建好了一个崭新的 Jenkins，但 Jenkins 部署完成后，还需要做一些基础的配置。

修改系统配置

比如我们要在 Jenkins 里把默认的 Shell 改成 bash，默认的 sh 是一个老的 Shell 环境，很多高级功能其实是不具备的，而 bash 是目前使用最多的。有的时候，你写脚本可能会遇到一些问题，所以建议你把默认的 Shell 改成 bash。

默认的管理员邮箱也可以修改，还有服务器默认的域名。除此之外，还有安全、时区、slave 节点。所有的全局性的配置都可以在 Jenkins manager 中管理，比如各种细节参数，你都可以在其中进行相应配置。

然后是安全，Jenkins 启动之后默认有一个自己的安全机制，无论你是要改成自己公司关联的安全认证体系，还是基于项目设置权限，都可以进行配置。

时区配置相对来说会比较复杂一点，在 Jenkins 里面配置时区需要修改系统的配置。如果你使用 docker 安装，可以用这样一个简单的办法来处理，首先删除原来的 docker 实例，接着在 docker 实例启动过程中加一个参数：-e JAVA_OPTS，在里面设置一个数据，比如改成北京时间，这个时候，你的 Jenkins 就可以自动更改为指定的本地时间。如果你没有设置，它默认显示的是美国时间，会影响到你的使用。

插件管理可以用于安装、更新插件，必要的时候需要配置代理以加速插件的安装。可以在 Available 里挑选需要的插件，常用的的插件是 git、pipeline、blueocean等，更多插件按需安装即可。

还有一个部分是 slave 节点，它在 Jenkins 的 Nodes 模块下面，你可以自己创建一个新的节点，这个节点主要是为了执行 job。通常 Jenkins所在主机称之为 master，是一个主控机，它要管理很多 job，所以它本身的任务比较重，需要把具体的job执行放到分布式的node上。

通常对每一个 job、每个任务的执行，我们不会在主机上直接执行，而是通过多台机器来进行分担。不同的机器，比如 Windows、Mac、Linux，它们的职责是不一样的，你可以通过节点来管理所有需要控制的资源。那么 slave 节点是在 manager Jenkins 下面的 manager nodes and clouds 里面，你可以写上自己的设备，比如这是我写的一个设备。后面你可以通过把任务与节点进行关联，在特定的节点进行运行。

slave 节点的连接方法，在前面我们启动 docker 的时候，用到了一个叫 50000 的端口，这个端口其实就是在这个地方使用的。8080 是 Jenkins 默认的对外访问的 UI 交互地址，而 50000 端口主要是 slave 节点与 Jenkins 之间进行通信的。创建一个节点之后，你可以使用 8080 端口连接 Jenkins，然后，通过 50000 端口建立真正的连接，所以你要确保这两个端口一定是开启并且配对的，不然你的 slave 是连接不上的。

一个 job 的组成部分

了解了一个系统的基本设置之后，我们来看一看一个基本 job 的重要组成部分。从图上可以看到，一个基本的 job 配置通常分为五大模块：

• 一个叫 General，是系统的通用配置；
• 一个叫 SCM，是源代码管理系统；
• 第三个是触发器，它最重要的特征就是可以根据研发的代码提交，自动执行对应的 job，所以这个 build trigger 触发器是一个比较重要的点，就有了它我们才可以自动分析代码，根据代码的变更自动触发一些行为；
• 还有一个是 build 构建，我们可以在这里面完成对系统的预设行为的构建，比如我要执行一个什么样的命令，跑哪一个测试用例，你可以在 build 里面来进行设置；
• 还有一个叫 Post-build Actions，测试完成之后我需要分析汇总报告，你可以在这个地方进行设置。

我们分别来看一下每个部分的设置。

首先是项目的通用设置，主要是用来配制系统的描述信息。然后是项目的其他配置，比如我的任务的当前状态是什么？我要在哪个机器上来执行？这些相关的配置都可以在这个地方来进行约束，这就叫 job 的通用配置。

第二个叫源代码控制 SCM，目前使用最多的是 git，其他的版本管理系统也都是支持的，只需要安装对应的插件即可。你可以在仓库里面写上 git 地址，然后去拉取分支进行构建。如果这个代码将来需要浏览，也可以配置 GitHub 地址，通常我们用的就是前两个，给另一个项目的地址，给另一个具体的分支。还有一些更细节的配置，比如代码 check 到本地之后，本地的文件名要不要放到子目录下面？你可以通过额外的行为来进行配置。

第三个是 biuld trigger，trigger 触发器可以允许你通过多种方式去触发某个任务，比如远程触发，通过脚本的方式发一个请求过来，系统就会自动执行对应任务。还有一个叫周期性构建 build，你可以写上一个时区，他用的时间格式跟系统里面的 crontab 是一样的格式，总共有 5 个卡位符，每个卡位符你可以用 * 表示其中的任何一个时间我都要执行。它有自己的语法，除以一个数字代表每隔多久执行一次。h 相对来说比较特殊一点，如果你所有的job都写 *，系统会在某一个整点时刻密集触发，会让系统的负载比较大，所以通常 Jenkins 建议你使用 h，系统会根据你的情况自动分配，把时间错开。

下面还有一个 poll scm，就是从我的代码管理里面定期进行拉取，看一下有没有新的代码变更，如果有代码变更，我将会触发一次构建；如果没有代码变更，它就等下一次检查。

我们在看第四个 biuld，主要是用来执行真正的任务，build 里面是一个基础的构建环境，再往下是说在执行过程中，执行哪些具体的命令。其实你可以在 add build step 里面添加更多功能，比如执行 Shell，执行某个命令，这里面可以通过插件扩展非常多的可执行的步骤。用得最多的仍然是执行 Shell，执行 Shell 可以让我们执行自动化脚本完成很多复杂工作。

最后一个 Post-biuld Actions，它的主要作用是在所有的结果执行之后，可以完成结果的汇总、分析、出报告，甚至发邮件、提醒、报警、自动提交 bug。在 Add Post-biuld Actions 里面有非常多的任务，你也可以通过插件继续扩展。

那么有了这些知识点，接下来你就可以去创建自己的 job 了，你可以看到我的 Jenkins 上的测试环境，创建了一个小小的 job，按照刚才的配置已经配置完成，你可以在这里触发构建，构建之后，job 就会多了一层执行分析结果。

具体的每个项目怎么配置呢？比如 ui 分化我怎么集成？接口测试怎么集成？我们会放在下一节课来给你去讲，比如测试结果，你可以点这个图了解一下，这次构建的有多少个测试用例？每个测试用例是成功还是失败？你都可以在这个地方查看。