下面是Jenkins的首页，如图所示。接下来介绍Jenkins Job相关的内容。

Jenkins Job介绍

Jenkins作为一个持续集成工具，它其实是由若干个Job任务或者Project项目构成了一个庞大的运维开发平台系统。你可以将平时的开发、测试、部署或者基础运维相关的工作任务通过创建一个项目或者任务从而保存在Jenkins任务列表当中，方便你在Jenkins平台下进行日常的开发、运维和维护工作。

在Jenkins平台下，我们的工作可以利用Jenkins内建模块或者特定的脚本语法，将我们的工作内容抽象成Jenkins Job（Jenkins任务），然后你可以在这个任务中通过配置相应的参数以及工具模块，从而作为一个可执行的任务，共享保存到Jenkins平台下，供日常工作中不同权限的人员重复build构建执行，这样就将传统的通过单机图形界面或者命令行脚本去配置执行日常任务，迁移到Jenkins这个共享平台下，去进行统一化的任务配置执行，这样就大大的简化了工作流程，方便日常的统一维护工作。

你每一次执行任务的结果记录称之为一个build构建，你可以通过查看这个build构建去获取到我们所需要的结果信息。最终Job任务执行后的build构建信息会保存在Jenkins上，作为build log日志。你可以通过查看不同时间点的log信息，可以去debug追踪任务执行过程中出现的各种问题。Jenkins后台也会通过build log日志的数量和大小，来监控当前Jenkins的健康状况。

Jenkins下所有的任务构建后的所有项目相关文件，例如克隆的仓库代码、Maven打包生成的编译包，你配置的参数文件等，这些都会保存在Jenkins主目录的work space目录下，并以当前任务名称命名的一个目录中，作为当前任务的work space(也就是工作区域进行保存)。你可以通过查看这个工作区域下的相关文件，去获取一些在任务日志中无法定位的问题细节，从而进行问题的深度查找，并解决一些相对困难的问题。

以上就是Jenkins Job任务相关的基础知识，从网上找了一张图片可以了解一下：

Freestyle Job与Pipeline Job介绍

接下来介绍Jenkins Job两种不同的任务类型，并学会掌握两者直接的区别与不同。

Freestyle Job是平时用的较为多的任务类型，它是Jenkins发行之初到现在用途最为广泛的任务类型，深受运维、开发、测试人员的广泛青睐。它有以下几个特点：1、需要在页面添加模块配置项与参数完成配置。你需要在其任务配置界面添加相应的模块配置项以及任务参数就可以构建一个满足不同工作人员的工作需求。Jenkins会默认在任务配置界面中布局所有模块，以及参数配置项，这样就非常容易地完成了任务的构建工作。2、每个Job仅能实现一个开发功能。由于Freestyle Job是Jenkins最早使用的任务类型，它针对开发环境中，不同的任务类型的串联可能会出现一些不足，每个Freestyle Job仅能实现一个任务功能。也就是说你只能在Freestyle Job中干一件事，这样就大大地降低了任务的执行效率。3、无法将配置代码化，不利于Job配置迁移和版本控制。Freestyle Job的所有配置只能通过前台手动去完成，你无法通过编写代码的方式来完成Freestyle Job的配置工作。这样虽然创建配置很直观，不需要抽象成代码的方式，但是当我们将Freestyle Job进行平行迁移时（其实就是将具体的Job迁移到其他Jenkins系统上）就会变得相对复杂很多。还有一个不足之处在于，默认的Jenkins没有一套完整的审计机制去记录和保存所有人的系统配置历史，也就是说我们无法知道谁曾经动过我的“奶酪”。4、逻辑相对简单，无需额外学习成本。Freestyle Job虽然有一些不足，但是它的逻辑相对简单，无需额外学习成本，你只需要参照对应的模块文档，就可以在Freestyle Job中找到对应模块的配置项，从而非常轻松的上手，并完成任务配置工作，这也是Jenkins深受新手青睐的一个重要原因。

Pipeline Job是目前推荐，也是业界比较流行的任务类型。Pipeline Job早期是Jenkins的插件，因此早期的Pipeline Job是不能立即使用的，需要你手动安装这个插件才能使用，由于Pipeline Job非常契合持续集成、持续交付、敏捷开发特性，所以越来越多的用户都会将它作为一个首选的Jenkins的插件，作为配置管理Jenkins项目的任务格式，后台Jenkins开发团队也意识到了这一点，已经将Pipeline Job内置了，并成为一种主流。Pipeline Job作为目前Jenkins重要的组成部分，它能够在Jenkins中实现持续集成和持续交付的管道。你可能要问这里的持续集成和持续交付是什么含义呢？它们在Jenkins中起到了什么作用呢？持续集成简称CI，是软件开发周期过程中的一种实践，通过将代码仓库与Jenkins集成，可以使开发人员每一次的代码提交都能够自动在Jenkins上进行任务的build构建，这样就能帮助开发团队第一时间发现问题和解决问题。持续交付简称CD，它是在持续集成CI的基础上，可以将构建好的软件版本通过Jenkins的自动化测试部署等多个程序，持续、安全、快速的交付到用户手中。这里的Pipeline Job就非常满足我们持续集成和持续交付的原则。它也有几个特点：1、所有模块、参数配置都可以认为是一个Pipeline脚本。Jenkins下的所有模块、参数配置都可以认为是一个Pipeline脚本，所以你就可以非常方便的调用Pipeline模块去编写业务逻辑。2、可以定义多个stage构建一个管道工作集。Jenkins可以通过编写多个stage作为项目集成部署过程中的每一个阶段，构成一整套管道工作集，进而串联所有工作。3、所有配置代码化，方便Job配置迁移与版本控制。Pipeline的所有配置最终都可以体现为一段代码，这样就非常方便我们进行Job任务的配置迁移，以及对我们所做的所有改动进行版本控制，将我们项目的所有改动都可以定位到代码层面上，便于后期的审计工作。4、需要有Pipeline脚本语法基础。Pipeline虽然有这么多优势，但是作为我们使用者需要去学习Pipeline的基础脚本语法，这使得你需要花费一定的时间去学习，但是当你掌握这个语法后，将会对后期的工作产生巨大的影响。

其实Freestyle Job与Pipeline Job两种任务最大的不同在于Freestyle Job方便配置，但不利于项目管理维护；Pipeline Job方便项目管理，但需要一些学习成本。所以需要结合自身情况来选择适合自己的任务格式。

Jenkins Job环境配置

接下来开始介绍Jenkins Job的环境配置，这个过程相对来说还是比较简单。

第一步，配置Jenkins server本地Gitlab DNS；你需要明确自己安装部署Gitlab虚拟机的IP，且需要启动该机器。然后在Jenkins所在机器的hosts文件内新增一条指向Gitlab虚拟机的DNS记录：

1
2
3
[root@jenkins ~]# vim /etc/hosts
# 文件末尾添加如下一条记录
192.168.2.131    gitlab.example.com

第二步，安装git client，curl工具依赖，你可以使用yum install -y git curl命令来进行安装：

1
[root@jenkins ~]# yum install -y git curl

第三步，关闭系统Git http.sslVerify安全认证，你可以使用git config --system http.sslVerify false命令来关闭，同时可以使用echo $?来验证是否成功关闭：

1
2
3
[root@jenkins ~]# git config --system http.sslVerify false
[root@jenkins ~]# echo $?
0

第四步，添加Jenkins后台Git client的user和email：

第五步，添加Jenkins后台Git Credential依据：

请注意上面必须是passworld类型，点击确定，之后出现下面的界面表示你已经成功添加了git的凭据：

Jenkins Freestyle Job构建配置

第一步，创建一个Freestyle Project，名称为test-freestyle-job，选择Freestyle Project格式：

第二步，编辑描述信息，完成第一步后页面会跳转到下面所示界面：

接着在描述那一栏填写：this is my first test frestyle job.。接着点击下方的This project is parameterized（参数化构建过程）。然后下拉菜单，首先选择Choice Parameter选项参数：

然后在里面填写build时的选项参数信息，具体包括名称、选项和描述：

之后点击添加参数，选择String Parameter文本参数：

第三步，配置gitlab参数，首先需要运行gitlab所在的虚拟机，并使用gitlab-ctl start命令来启动gitlab服务，其次选择first-repo项目，并粘贴该项目的SSH克隆地址：

接着回到Jenkins的test-freestyle-job任务，选择git管理，然后按照下图进行操作：

第四步，添加build，其实就是你需要执行的信息：

然后在命令选项框内输入以下信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#!/bin/sh

export PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin"

# Print env variable
echo "[INFO] Print env variable"
echo "Current deployment envrionment is $deploy_env" >> test.properties
echo "THe build is $version" >> test.properties
echo "[INFO] Done..."

# Check test properties
echo "[INFO] Check test properties"
if [ -s test.properties ]
then
  cat test.properties
  echo "[INFO] Done..."
else
  echo "test.properties is empty"
fi

echo "[INFO] Build finished..."

然后点击应用和保存按钮，页面会自动退出当前的build界面。

第五步，点击“Build with Parameters”，开始运行任务：

之后会进入构建前的参数选择界面，前面设置了选项参数，这里选择dev，下面的version是文本参数，默认为你前面设置的1.0.0，当然你可以自己修改：

然后点击下方的“开始构建按钮”按钮：

可以发现页面的左下方就多了一个任务构建的进度条，将鼠标放上去：

说明项目已经构建完成了，然后点击那个小圆球，可以看到右侧已经成功输出了执行结果：

Jenkins Pipeline Job介绍

作为Jenkins目前主推的任务构建模式Pipeline Job，它的管道块连接子任务的主体架构逻辑已经被广泛的运用在大中小型项目部署、交付构建当中。这里推荐有项目经验的人通过本篇的学习，尝试将自己的项目迁移到更加容易维护管理的Pipeline Job任务模式下。接下来介绍Pipeline Job的编写规范。

Pipeline简介

Pipeline基础架构

1.所有代码包裹在pipeline{}层内；
2.stages{}层用来包含该pipeline所有stage子层。它用来将Pipeline管道分为若干个管道块，每一个管道块可以做一件事情，且彼此之间不受任何影响；
3.stage{}层用来包含具体我们需要编写任务的steps{}子层。stage后面跟管道名称，这里的一个stage就是一个个的管道块，你可以在里面添加需要编写任务的steps{}子层；
4.steps{}用来添加我们具体需要调用的模块语句。如sh，echo等。

agent区域

agent定义pipeline在哪里运行，可以使用any，none，或具体的Jenkins node主机名等。举个例子来说，如果我们要在node1主机上执行，那么可以写成：agent{node1 {label 'node1'}}，但是并不推荐新手这么操作，新手还是使用any为好，这样会随机在一台Jenkins主机上执行构建：

environment区域

environment区域用来定义当前Pipeline任务的系统环境变量的配置。你可以使用“变量名称=变量值”的形式来定义我们的环境变量；同时你可以定义全局环境变量，它应用所有stage任务。也可以定义stage环境变量，应用于单独的stage任务：

script区域（可选）

script区域是可选的，它定义在steps区域下（通常为script{}），可以编写groovy脚本语言，用来进行脚本逻辑运算：

常用steps区域

我们大部分的模块调用或者逻辑语法编写都是在这个区域中展开。你可以使用echo来打印输出静态或者动态语句，到我们build构建任务log输出内。也可以使用sh来调用Linux系统的shell命令，去在Pipeline下编写shell脚本。还可以使用git url来调用git的相关模块进行git操作：

Jenkins Pipeline Job构建配置

第一步，创建一个Pipeline Project，名称为test-pipeline-job，选择流水线格式：

第二步，编辑描述信息，完成第一步后页面会跳转到下面所示界面：

接着在描述那一栏填写：this is my first test pipeline job.：

第三步，pipeline脚本配置。首先获取当前Jenkins节点的唯一标识Id：

然后编写pipeline脚本，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
#!groovy

pipeline {
    agent {node {label 'master'}}

    environment {
        PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin"
    }

    parameters {
        choice(
            choices: 'dev\nprod',
            description: 'choose deploy environment',
            name: 'deploy_env'
            )
        string (name: 'version', defaultValue: '1.0.0', description: 'build version')
    }

    stages {
        stage("Checkout test repo") {
            steps{
                sh 'git config --global http.sslVerify false'
                dir ("${env.WORKSPACE}") {
                    git branch: 'master', credentialsId:"957f4bef-6d33-416d-a28e-1d489a7905a8", url: 'https://gitlab.example.com/root/first-repo.git'
                }
            }
        }
        stage("Print env variable") {
            steps {
                dir ("${env.WORKSPACE}") {
                    sh """
                    echo "[INFO] Print env variable"
                    echo "Current deployment environment is $deploy_env" >> test.properties
                    echo "The build is $version" >> test.properties
                    echo "[INFO] Done..."
                    """
                }
            }
        }
        stage("Check test properties") {
            steps{
                dir ("${env.WORKSPACE}") {
                    sh """
                    echo "[INFO] Check test properties"
                    if [ -s test.properties ]
                    then 
                        cat test.properties
                        echo "[INFO] Done..."
                    else
                        echo "test.properties is empty"
                    fi
                    """

                    echo "[INFO] Build finished..."
                }
            }
        }
    }
}

请注意需要将credentialsId替换为刚才自己获取的credentialsId，以及url为自己待克隆的项目地址，如https://gitlab.example.com/root/first-repo.git。该代码其实和freestyle job表达的意思完全一样，首先是设置当前为哪种环境，其次是当前build版本信息。第一个stage任务（Checkout test repo）的意思是从gitlab仓库拉取仓库代码到Jenkins当前Job的workspace下，下载下来的代码中包含我们的test.properties文件，因此你需要提前去你gitlab仓库的test-repo项目中新建一个空白的test.properties文件：

第二个stage任务（Print env variable）的意思是打印输出之前配置的环境参数，并将其写入到test.properties文件中。第三个stage任务（Check test properties）的意思是检查test.properties文件是否存在。

然后将前面编写的pipeline脚本拷贝进去：

可以发现构建出错了：

查看日志，可以发现问题：

错误提示为：没有找到对应参数的变量。那是因为首次构建pipeline job时，参数没有被引用到当前pipeline job当中，你需要返回test-pipeline-job的主界面，此时的“立即构建”按钮会变为“Build with Parameters”，然后点击“Build with Parameters”：

使用默认的参数，点击下方的开始构建：

当看到下面的结果时，表明已经执行成功了：

你还可以点击左侧的蓝色小圆球，查看输出日志信息：

Running on Jenkins in /var/lib/jenkins/workspace/test-pipeline-job表示你所有的信息都会存到/var/lib/jenkins/workspace/test-pipeline-job目录下。