Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具

持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程

可以简单将jenkins理解为一个代码部署工具。
在没有持续部署工具之前，开发部署代码到服务器上是需要一定的流程的，比如合并代码，然后相关人员将代码更新到服务器（旧代码覆盖），运行一些指令让新代码生效，然后观察运行情况。
流程听起来好像还挺简单的，但是谁能保证部署人员的每一步都没有差错呢？需要部署的服务多的话，也很费时间。

一般情况下，人工部署到服务器的步骤都是固定的，那是不是表示可以动一些“歪点子”（脚本程序），让脚本替代部署人员去做部署的工作呢？懒人表示肯定能行。

Jenkins就是按照人工部署的步骤，代替人工操作，将代码部署到指定服务器并运行的工具（老板表示这个工具非常好，又可以炒人了）。

我们本章以tomcat web为例进行jenkins的入门操作。考虑到本地配置jenkins和tomcat服务会让入门人员产生一定的混淆，所以本章以一台电脑和远程可访问的服务器进行配置。我的预想是在本地配置jenkins服务，在远程服务器中部署tomcat服务。其实都可以在本地电脑上配置，思路上是一样的，只是环境配置不太一样，这个可以去网上搜搜安装教程。

在实践之前，我们先思考几个问题：

1、jenkins是怎么部署tomcat运行环境的？
2、jenkins怎么识别我想要它部署的代码？或者代码是怎么上传到服务器上的？

首先，Jenkins只是根据人工部署代码的步骤去部署代码到服务器，并不能去配置服务器的运行环境，运行环境还是要自己配置好。所以还是自己去服务器上配置tomcat运行环境。但是jenkins可以安装一些库之类的。
想要让jenkins将指定代码部署到服务器上，我们就得告诉jenkins从哪里下载代码，并告诉jenkins部署到哪台服务器。
jenkins的插件会去远程仓库下载代码，然后通过配置传送到指定服务器上，所以我们可以将html文件（即代码）上传到远程仓库，让jenkins去更新到服务器。
注意：为了方便理解，这里就用很简单的例子进行讲解——部署tomcat运行的html文件

根据以上思路，我们目前需要操作：
1、手动在服务器配置tomcat服务并运行
2、本地配置jenkins服务，并配置项目
3、让jenkins部署代码并让代码运行（一般叫构建）

远程服务器配置

运行tomcat服务需要有jdk环境，所以远程服务器需要先安装jdk

Linux安装jdk

下载jdk：https://www.oracle.com/java/technologies/downloads/
可以通过arch命令查看下载哪个tar.gz包


复制对应安装包的链接，通过curl -o 下载后文件名称.tar.gz 安装包链接的方式下载安装包
远程服务器命令：curl -o jdk.tar.gz https://download.oracle.com/java/20/latest/jdk-20_linux-x64_bin.tar.gz

如果服务器可以使用wget命令的话，可以通过wget命令下载：wget https://download.oracle.com/java/20/latest/jdk-20_linux-x64_bin.tar.gz
下载成功后，解压

解压后多了个目录（我这里是jdk-20），进入该目录，可以看出有bin目录和lib目录

要将bin目录和lib目录配置到系统环境配置中，类似于windows设置系统环境变量的作用，让系统可以根据路径查到对应的命令文件
vi /etc/profile命令打开配置文件，输入i进入编辑模式，添加如下内容后，按Esc键退出编辑，然后输入:wq保存退出：

export JAVA_HOME=/root/jdk_ins/jdk-20
CLASSPATH=$JAVA_HOME/lib/
PATH=$PATH:$JAVA_HOME/bin
export PATH JAVA_HOME CLASSPATH

注意：JAVA_HOME就是我们解压的jdk目录

编辑成功后，输入如下命令让修改后的配置文件生效，命令：source /etc/profile
然后输入java -version命令查看jdk是否生效，如下正常输出了java version的版本信息就表示安装成功了

配置tomcat服务

服务器的jdk配置好之后，就可以配置tomcat服务了。首先先下载tomcat包
tomcat官网：https://tomcat.apache.org/

新建一个tomcat_web目录，用来存放下载的tomcat安装包，然后解压


一开始访问服务器的8080端口，提示失败，怀疑是服务器的端口没有开放，所以又去开放了8080端口（每个服务器的开放端口命令可能不太一样，腾讯云服务器、阿里云服务器都有控制台可以设置，我的服务器没有控制台，但是可以通过firewall-cmd命令开放端口，具体如下：

firewall-cmd --query-port=8080/tcp是判断8080端口是否开放，为no表示没有开放，为yes表示开放了；
firewall-cmd --add-port=8080/tcp --permanent：添加开放的端口8080
firewall-cmd --reload：重载添加的端口
将8080端口开放后，访问服务器8080端口，访问正常

在tomcat解压目录下，进入/webapps/ROOT目录，编写test.html内容


服务器的tomcat服务配置好了，接下来来配置本地的jenkins服务

Jenkins配置

window安装jdk

Jenkins是使用Java编写的，所以需要安装并配置JDK环境
Jenkins对JDK版本是有要求的（具体的可以看Jenkins官网：Java requirements）

目前Jenkins最新版本是2.375，所以JDK11~JDK17是可以满足要求的，选择JDK17的版本，JDK下载地址：https://www.oracle.com/java/technologies/downloads/

选择免安装版本，下载完成后，解压到指定目录，然后进入解压后的目录中，直到bin目录下，bin目录存放了一堆java的可执行文件，将bin目录配置到系统变量Path中

打开cmd窗口，输入java -version，命令正常运行则表示JDK环境配置成功

Jenkins安装

(https://www.oracle.com/java/technologies/downloads/)
Jenkins下载地址：Jenkins

下载jenkins.war，管理员身份打开cmd，使用java -jar jenkins.war来启动jenkins服务（默认占用的是8080端口，如果想占用其他端口，启动命令：java -jar jenkins.war --httpPort=端口号）

浏览器打开http://localhost:8080/页面，首次打开jenkins服务页面需要先解锁Jenkins（即管理员密码），解锁密码页面有说明

不安装推荐的插件，插件后面有需要再自己安装


可以创建一个管理员用户，后续就使用该管理员登录

后面直接按照指示即可，最后进入jenkins首页

构建项目

jenkins是以项目的维度去管理的，我们先创建一个项目（item）

然后进入了项目的Configure（配置）页面，在这里配置相关内容，基本有如下内容：

• General：常规配置，简要说明项目内容，以及构建（运行）项目的一些管理
• Source Code Management：源码管理，即从哪里下载源码，源码必须存放到jenkins可以下载的地方，本地电脑经常变换，也没有插件支持，所以放在可访问的远程服务器比较方便，比如github、svn、码云等平台
• Build Triggers：构建触发器，即什么情况下会触发构建（重新运行）
• Build Steps：构建步骤，一般情况下，提交修改后的代码后，要使代码生效，我们都需要在更新代码的基础上去执行一些命令，让新代码生效，Build Steps可以设置这些命令

emmmm，这些概念可以先不理解，后面有它们出场的舞台。

我们想让jenkins为我们部署代码并运行，就得让Jenkins知道去哪里下载代码，还得告诉Jenkins是部署到哪个服务器

代码维护

我们写代码一般是在本地电脑上写的，然后代码是在服务器上运行的。可能有人就想了：我代码在本地，jenkins也在本地，是不是可以让jenkins识别到本地的路径，将本地的代码直接更新到服务器上去？
也不是不行（我不会）如果代码是自己一个人维护的话可以这样，但是一般项目的代码不是一个人写的，合并需要时间和团队成员的配合，项目代码也是在github等可访问的远程仓库托管，所以我们还是将代码维护到远程仓库，让jenkins去远程仓库下载，这样就算你换了新电脑，也不用去旧电脑copy代码过来，只需要配置Jenkins服务就可以了；多人的项目，大家按照指定规则将代码合并到远程仓库，就不用在部署前通知成员去合并了。

这里选择Gitee为远程仓库来托管html代码，上传到Gitee需要git工具，我们需要安装支持git命令的插件

jenkins服务的git插件依赖于本地的git工具，即本地需要安装git（网上有安装教程），打开命令行（不要在git安装目录下打开命令行）并输入git -v，有git version版本号出现，表示git安装成功

如果安装插件比较慢的话，可以将插件下载地址替换成国内镜像地址
替换方法参考这篇博客：解决 jenkins 插件下载失败问题 - 配置 jenkins 插件中心为国内镜像地址


安装成功后，重新进入项目的Configure配置页面

勾选git，配置远程仓库信息和登录信息

Jenkins的git配置好后，点击"Build Now"进行构建，Jenkins会在本地电脑构建，因为我们只配置了远程仓库的内容，所以这次构建只是下载代码（并没有上传到服务器，上传到服务器还需要进一步配置）

配置服务器信息

Jenkins下载代码运行成功后，我们还得告诉Jenkins要将代码部署到哪台服务器，即让Jenkins将下载的代码上传到到远程服务器，这一步也需要用到插件：Publish over SSH

安装好Publish over SSH插件后，在【Manage Jenkins】【Configure System】的Publish over SSH模块下配置远程服务器连接信息

服务器连接信息配置成功后，就可以在项目中进行使用了

配置到了这里，我们梳理一下我们可能达到的情况：将https://gitee.com/wenxiaoba/jenkins_demo.git的代码上传到43.252.231.68服务器的/root/jenkins_test目录下。
远程仓库的代码如下：

构建

从Console Output来看是构建成功了，我们去服务器上看看：

从服务器上看也是上传成功了，也就是说我们可以让Jenkins将代码部署到服务器的指定位置。
我们前面步骤中，安装了tomcat服务，tomcat服务的工作目录是其解压目录下的/webapps/ROOT，我们重新配置下项目中的Send build artifacts over SSH，更新其远程目标目录为tomcat的工作目录

在服务器对应目录下查看，对应目标目录下已成功上传

互联网访问wen.html文件：

可以正常访问。
到这里，基本上后面修改了本地代码，只需要更新到远程仓库，然后在Jenkins平台上构建，就可以让Jenkins将代码部署到服务器，不用自己手动去部署到服务器了。
为了方便理解，例子是用的最简单的例子，好像没省多少人力，但是如果是大型的网站呢？

Jenkins基本内容

入门实践基本上对Jenkins有一个初步的了解了，接下来对Jenkins的一些概念和配置进行详细说明

Jenkins的3个概念

Jenkins有3个重要的概念：Job(工程)、plugin(插件)、workspace(工作空间)

• Job(任务/工程)
  • Job就是我们本章操作的“项目”，新建的“Item”，我们一般以项目的维度去管理，从Jenkins角度理解，就是它的工作或任务了
• plugin(插件)
  • Jenkins提供了一个平台，通过各种插件来完成一个Job，类似于我们电脑的window系统，window系统提供了一个平台，然后我们可以通过各种软件（插件）来工作或娱乐。
  • 想让Jenkins干活时，先找找有没有对应的插件可用。
• workspace(工作空间)
  • Jenkins是通过文件形式来存储和管理数据的，我们在通过项目的Console Output可以看到当前项目的工作目录
  • 每个项目都有一个独立的工作空间，用来存放Job涉及到的数据/文件，以及任务执行完成后生成的数据/文件

Manage Jenkins

Manage Jenkins下主要有一些管理配置，比如插件管理、系统配置、用户管理等

• Global Tool Configuration：简称全局工具配置管理，如果安装的插件有多个版本，或插件依赖的运行工具有多个版本，就可以在这里进行设置，全局生效的。
• Manage Plugins：插件管理，即在这里安装、更新、卸载插件
• Configure System：一些基本的系统配置
• Manage Users：用户管理，比如用户的新增、删除等操作

Configure System

一些基本的系统配置如图：

如果有安装插件，【Configure System】也会显示插件的一些基本信息，有些插件数据就可以在这里配置。

系统公告

如果想提醒每一个进入Jenkins平台的人员一些注意事项，可以通过【Configure System】的System Message进行配置

如果想使用HTML的内容，需要安装支持HTML的插件，在【Configure Global Security】中，将Markup Formatter切换到HTML，然后回来【Configure System】，编辑System Message的HTML内容

规范项目名称

【Configure System】中，勾选Restrict project naming，选择“Pattern”，在Name Pattern中设置正则匹配规则，Description中进行描述，点击“Save”进行保存后，创建项目时项目名称就必须符合指定的规则了

项目内配置

Discard old builds定时清理构建数据

项目在创建并构建后，会有持续的构建，这些构建数据都会被缓存起来，但是项目是不断的更新的，有一些旧的构建数据就没必要还保留了，减少空间资源的占用。

Source Code Management源码管理

源码可以通过git、svn等工具进行管理，我们需要安装对应的插件，然后配置源码远程仓库地址、登录帐号、分支信息等。源码的git、svn插件只是在Jenkins和Jenkins所在主机间作为一个桥梁，让Jenkins可以通过调用主机的命令行去下载源码，所以主机需要安装对应的代码管理工具，比如git

大部分项目是通过git进行源码管理的，插件安装Git

在项目的Source Code Management中配置远程仓库信息，其中登录帐号信息的可以有多种方式：

• Username with password
• SSH Username with private key
• Secret file
• Secret text
• Certificate

常用的是Username with password和SSH Username with private key
勾选Git后，点击Credentials下的Add添加帐号信息

Username with password

SSH Username with private key
这个需要在远程仓库中配置SSH公钥数据，至于生成私钥公钥的步骤网上有教程，Gitee上也有，这里就不具体说明了：

Build Triggers构建触发器

Build Triggers，即如何触发构建，触发构建的方式总体有2种：手动触发和自动触发
手动触发就是人为去触发构建，即自己去点击构建按钮

自动构建就是Jenkins自己去触发构建，但是达到什么条件它才触发构建，是我们要进行设置的

定时触发构建Build periodically

定时触发构建即Jenkins按照指定的时间自动构建，在Build Triggers的Build periodically处设置触发时间

Build periodically设置时间是有格式的：
MINUTE HOUR DOM MONTH DOW

• MINUTE：分钟，数值为0-59，表示在第几分钟
• HOUR：一天中的小时，数值为0–23，表示在一天中的几点触发
• DOM：一个月内的天数，数值为1–31，表示在每月的几号触发
• MONTH：月份，数值为1–12，表示在哪个月触发
• DOW：一周的天数，数值为0-7，0和7都表示周日，1、2、3、4、5、6表示周一、二、三、四、五、六。即表示周几触发

相关格式和数值了解之后，还有一些英文符号：

• *：表示匹配任意值，即都满足，如果对字段的所有值都要满足的时候，就可以使用
• M-N：取值区间，表示连续的从M到N，即M-N之间的数值都需要
• */X：间隔区间，表示间隔X的时间段去执行
• M-N/X：从M开始，每隔X，直到N结束
• A,B,...,Z：枚举，就是在A、B…Z中的时候触发

练习：

题目	答案
每天晚上20点整自动执行	0 20 * * *
每周一0点15分开始执行	15 0 * * 1
每周一、三、五晚上8点整执行	0 20 * * 1,3,5
每周一到周五晚上8点整执行	0 20 * * 1,2,3,4,5 或0 20 * * 1-5
一周内每隔2天的晚上8点整执行	0 20 * * */2
每月1号23点15分执行	15 23 1 * *
2周执行一次，在周一3点开始执行	0 3 * * 1-1/2
每天16点到23点，隔3h执行一次	0 16-23/3 * * *

将内容填写进去后，移除光标，会显示自动构建的时间安排：

如果想看自己的配置是否符合预期，可以在cron模拟网站上看看预期情况：crontab.guru/

定时触发构建一般用在定时任务或自动化执行的情况下，是一定会去构建（或执行）项目的。

定时检查更新Poll SCM

一般情况下，开发在实现了一部分代码，并可以整合的时候，就合并到远程仓库上去，Jenkins定时检查并更新服务器代码。避免开发一次性提交太多代码导致冲突，也能让测试人员尽早介入测试，越早发现问题成本越低。团队开发中，会规定开发在某个时间前更新迭代的代码（比如下班前更新功能开发完成的代码），让开发养成及时更新代码的习惯，避免后面因为代码量过大导致部分代码被遗漏的情况。
定时检查是在项目中的【Build Triggers】下的Poll SCM下配置的，配置规则与Build periodically的一致，两者的区别是：Build periodically是定时去构建，Poll SCM是定时去检查代码有没有更新，有更新才构建，无更新就不构建

Build Steps构建步骤

一般情况下，部署代码不仅仅是将代码上传到服务器指定目录那么简单，前面的例子是因为tomcat服务不用重启就可以访问到更新的html，有些服务是需要执行代码才会更新，比如java应用、python应用。这个时候就可以通过Build Setps配置执行命令，让Jenkins通过本地或远程服务器的命令行工具去执行命令。一般情况下是在远程服务器上执行命令，以下通过例子进行实践
以前面的例子（Jenkins+tomcat）为基础，在Jenkins构建时，生成time.html，显示当前时间，并能通过tomcat web服务进行访问

Build Environment构建环境配置

Build Environment可以设置构建前后的环境配置，比如构建前将服务关闭，或者构建前安装某些指定的第三方库之类的。

因为Build Steps也可以进行构建后的环境配置，所以Build Environment一般用来进行构建前的环境配置。
我们以【Build Steps构建步骤】中的例子为基础，在构建前生成一个pre.html文件，也是保存当前时间，并等待2秒后在进行下一步工作

访问pre.html和time.html，结果如下：

我们看【Build Steps】和【Build Environment】的配置，2者基本上都是SSH Publishers配置，从这里可以看出来，【Build Steps】和【Build Environment】基本上配置是一样的，只是执行顺序上有差别。

Post-build Actions构建后操作

Post-build Actions，一般是指在构建完成后的操作，比如邮件通知相关人员构建结果之类、或者触发自动化跑批执行等。这一部分依赖于插件，后面的章节会有实践涉及到这一部分，这里就不详细讲解了。