Jenkins架构：

概念：
主节点（master）：Jenkins所在节点
从节点（Slave）等同于代理（Agent），即目标节点
任务（task）等同于 项目（project）、工程

原理：主节点选一个节点（主从都有可能），下发构建任务job，得到结果再进行分发。控制台输出中可以看到选择了哪个节点
安装Jenkins前准备：主从节点都安装git客户端（svn）、jdk、Maven，安装在同一个目录下

第一步、新建任务-可以直接新建，也可以拷贝已有项目配置

• 直接新建一个全新的项目：

1）点击【新建任务】

2）输入任务名称

3）选择“构建一个maven项目”

4）点击【确定】，进入配置页面

• 拷贝已有项目（新建项目后带有被复制项目的配置，再根据情况修改配置）

1）点击【新建任务】

2）输入任务名称

3）复制处输入需要复制项目的名称，可下拉快捷选择

4）点击【确定】，进入配置页面，此时配置页面带有复制的项目配置，根据本项目需要修改即可

第二步、修改配置

如果是新建任务，则直接进入配置页面修改配置；

如果是已有任务，则右上角查找项目名称，回车后进入此项目空间，左侧点击【配置】按钮，进入配置页面；或者是列表直接找到项目名称，点击项目名称进入此项目；

• 描述
• 纯文本，类似于备注，说明项目名称、前后端等等；

• 丢弃旧的构建-Discard old builds
• 配置build保留的次数与天数；发布包保留次数、天数

每次jenkins job执行build后，会在服务器上留下build记录及发布包，这些内容会占用磁盘空间；默认配置是不勾选Discard old builds的，此时默认值为365，显然这个值过大了；

Jenkins job在每次build结束后（无论成功还是失败），都会自动执行Discard old builds，释放磁盘空间；

因此根据磁盘空间来设置选项，如果磁盘空间充足，则均为15，如果磁盘空间不足，则均设置为3；当然也可根据实际需求来设置；

如下图配置也可：

 

 其中“发布包保留天数”和“发布包最大保留”，这两个选项是通过 Discard old builds右下角【高级】按钮控制显示的；

 以上内容转载及参考文章：删除Jenkins旧的构建来释放磁盘空间_我家小宝_朱朱的博客-CSDN博客_jenkins 删除builds

• 限制项目的运行节点
• 如果需要选择此项目的运行节点时则选择，否则可以不选择
• maven项目未勾选此选项，如何判断选择哪些服务器打包？个人理解：会选择jenkins系统管理-节点管理中，用法选择“Use this node as much as possible”

1、节点选项背景：jenkins安装在一台服务器上，如果所有的jobs均在此服务器上运行，当jobs运行太多时，会形成等待，为了提高效率，提出节点的概念：见本文开头的jenkins架构，jenkins安装的服务器被称为master机，其他服务器均被称为slave机，在master和slave上均可进行 job build；

如果打包过程中提示需npm update等，均需要远程对应的slave机器，slave机器的ip在jenkins配置中不可见，需要额外记录；

2、勾选“限制项目的运行节点”

标签表达式中填写节点名称或节点标签；

如果选择主节点，则填写主节点名称‘master’；（未验证填写主节点标签是否可以，本身主节点标签可以为空，此时如果想配置主节点，只能填写主节点名称）

如果选择slave节点，则填写从节点标签；（填写从节点名称报错，未查找原因）

  如果已设置节点，可以查看或修改设置，点击右侧的【设置】按钮，进入设置界面（位置在 系统管理-节点管理）：

 如果未设置slave节点，需要先进行设置，位置为系统管理-节点管理

转载：jenkins配置slave节点 构建项目并执行操作 - 彩笔杀手 - 博客园

• 源码管理
• 源码仓库地址及账号

上图示例为SVN；

1）Repository URL:svn代码地址；

如果根据指定版本号的代码打包，则在svn路径后+@版本号，其中版本号查找svn log的“版本”即可获取；

svn代码层级规则：后端代码，在本svn URL下，可见 pom.xml文件即可；

2)  Credentials（证书）：

 下拉选择svn用户名，第一次增加时需要点击【添加】按钮进行添加；

选择或添加的用户名需要有本项目svn代码权限；

• Check-out Strategy
• 打包后对于workspace下的脚本生成策略

 正常按以上选择即可；

以下为具体的选项：

 

具体见：Jenkins创建job时Check-out Strategy各个选项详细说明（含图）_russ44的博客-CSDN博客  

• 构建触发器
• 当某个事件被触发时，自动重新构建项目。
• 非必须，一般都通过build now手动执行构建；当然了解了触发器，可以根据触发器形式打造理想中的构建形式。

1)Build whenever a SNAPSHOT dependency is built

当job依赖的快照版本被build时，执行本job；即当代码有更新时就构建项目；（不理解）

2)Build after other projects are built

作用：配置关注的项目，当关注的项目构建后，构建本项目

3)Build periodically：隔一段时间定时build一次，不管版本库代码是否发生变化；

日程表规则：

MINUTE Minutes whinin the hour(0-59)

HOUR  The hour of the day(0-23)

DOM The day of the month(1-31)

MONTH The month(1-12)

DOW  The day of the week(0-7) where 0 and 7 are Sunday.

第一个是代表分钟 H 表示随机 
第二个是代表小时 9-15/4 9点到下午三点期间的每隔4个小时 
第三个是代表天 * 任意一天 
第四个是代表月份 1-11 表示1到11月份 
第五个是代表星期 1-5 表示工作日

没有用到 H 随机的话，不要加括号 
H(9-18) 9点到18点 中随机的一个点 
eg： 
* * * * * 表示任何一个时间段，同一个时间都可能会触发执行。不建议使用 
H/30 * * * * 表示每天每隔 30分钟构建一次 
H 4-19/3 * * * 表示，一天的凌晨点到下午7点，每隔3个小时构建一次 
* * 3-5 * * 表示，每个月的3号，4号，5号 都会被构建，具体时间未知 
* * * * 1-5 表示，工作日时会构建，具体时间未知 
H/30 8-19/3 1-28 1-11 1-5 表示 在1月到11月中的1号-28号，每个工作日，早晨的8点到下午7点每隔3.5个小时会触发构建（个人怀疑此条规则说错了，H/30意思就是每30分钟一次）

H */12 * * * 表示每12小时会触发构建

H/30 11-13/1 21-28 4-5 1-5  经验证，为11:20到13:50，每隔30分钟构建一次（11:20、11:50、12:20、12:50、13:20、13:50），而且是到13点50才结束

4）Poll SCM，即轮询构建

指定一段时间间隔去扫描代码仓库的代码是否有变更，如果有，则出发项目构建；

日程表的规则应该是遵循上述规则，未验证；

• 构建环境
• 非必须，但建议勾选Delete workspace before build starts。勾选此选项后，每次打包前jenkins会先删除工作区代码再打包；如果不勾选此选项，开发人员删除某些代码文件，但是此文件仍然在工作区保留，打包时仍然会带着打包，有可能会通过打包引起的bug；

因为每次重新构建时都会从配置的源码地址取到最新的项目代码放到工作区中，但是Jenkins只会将代码放到工作区中，而不执行删除操作，同样的文件会覆盖掉，但如果新的代码中有些文件已经删除了，则在工作区中还会保留。所此需要构造这个选项。

• Pre Steps
• 构建前操作，不需要配置

• Build

1）Root POM:对应的pom.xml路径，此路径是相对于workspace的相对路径；注意：是相对位置，如果该文件不存在，会有红色字提示。 

2）Goals and options:一般为空即可，如果有需要再添加内容；

可添加maven命令。clean package -Dmaven.test.skip=true(清除以前的包，重新打包，并跳过测试)  

3）【高级】可以点击高级按钮，配置maven（此处配置可以在系统设置中设置好，然后每次新建任务就不需要设置了）

此图为网上转载，未实际设置；

 4）build设置高级处，前置条件是jenkins系统管理中设置过maven，否则弹出提示要求设置maven

系统管理-全局工具配置-Maven

有个疑问是这是全局配置，并未指定具体哪个节点的maven，甚至有的节点可能没有安装maven，有的节点maven打包会有问题，有的节点maven打包正常；那么在jenkins项目配置时，是如何选取正确的节点并进行打包的呢？

• Post Steps
• 构建后操作，不需要配置 (因为默认就会选择一项，所以具体此选项是否有其他作用，如与“构建后操作”有关，未验证)

下图为新建项目默认勾选

1）Run only if build succeeds：仅当构建成功时执行
2）Run only if build succeeds or is unstable：仅当构建成功或者不稳定时执行
3）Run regardless of bulid result：不管构建结果如何，都执行

4）【Add post-build step】点击添加对应操作
Execute Windows Batch command：执行Windows批处理命令
Execute shell：执行shell脚本
Invoke Ant：调用Ant脚本
Invoke Gradle script：调用Gradle脚本
Invoke top-level Maven targets：调用Maven项目等
 

sonar：

在pre steps或者post step进行配置。区别是构建前还是构建后。

选择Execute SonarQube Scanner

JDK:选择jdk版本

Analysis properies：分析属性

sonar.projectKey=${JOB_NAME}      #自定义
sonar.projectName=${JOB_NAME}       #自定义
sonar.projectVersion=1.0      #版本
sonar.sources=.      #源码目录
sonar.java.binaries=.      # .class目录
sonar.sourceEncoding=UTF-8      #编码
sonar.language=java      #语言
sonar.scm.disabled=true      #
sonar.java.source=1.8      #

• 构建设置
• 勾选后会有邮件通知，此处不设置

     未验证

•  构建后操作
• 用处：自动部署。如果不需要自动部署，此步骤可省略；
• 原理：Jenkins会在工作区中项目根目录下去寻找 Source files 中指定的jar文件，去掉 Remove prifix 指定的前缀后，将文件存放在 Remote directory 指定的位置下（如果Remove prifix中没有设置，则存放的位置会变成/data/appuser/hello-world-web/target），然后执行 Exec command 中的脚本命令，构建项目（当然，只有当点击了“构建”才会执行这些命令）。

选择 Send build artifacts over SSH（使用SSH发送artifacts到服务器）

为什么选这个？

因为此处Jenkins和项目没有部署在同一个Linux机器上。这个插件可以通过ssh连接其他Linux机器，如果没有这个选项，则可以安装插件：系统管理→管理插件→可选插件→Artifact Uploaders→Publish Over SSH

Source files: rest-gamma-app/target/rest-gamma-app-1.0-SNAPSHOT.jar
Remove prefix:rest-gamma-app/target/
Remote directory:/home/rfcj/jar/
Exec command:

echo "1、开始部署，关掉jar包进程"
kill -9 $(netstat -nlp | grep :8080 | awk '{print $7}' | awk -F"/" '{ print $1 }')
sleep 3
cd /home/rfcj/jar/
echo "2、启动新jar包进程"
nohup java -jar rest-gamma-app-1.0-SNAPSHOT.jar > /home/rfcj/jar/jar.log 2>&1 &
echo "3、重启完成"

以下自动部署应该是以linux为例，如果是windows，不确定是否还能够使用Publish over SSH插件进行配置；

1）Name：选择需要自动部署的目标机器，名称需在jenkins系统管理-系统设置-Publish over SSH中提前配置；

2）Source files：打包后生成的部署包文件目录（在jenkins工作区）；为相对路径，相对于svn脚本路径，一般为“rest-gamma-app/target/rest-gamma-app-1.0-SNAPSHOT.jar”；

3）Remote prefix：去掉Source files中jar包的前缀，一般为“rest-gamma-app/target/”；

4）Remote directory：部署包存储路径，为自动部署目标机器中相对于jenkins系统管理中配置目标机器根路径的相对路径；如jenkins系统管理中配置为‘/’，此处即为jar包所在绝对路径；

5）Exec command：自动部署所需命令；前面的几个配置是将打包后的部署文件放置在需要自动部署目标机器的目标路径中；此处是放置部署包后，需要执行的命令；

a）如果部署时只需要替换部署包，不需要执行任何命令，则此处为空；

b）如果部署时在替换部署包后，需要执行什么命令，都可以在此处编制

• cd 到部署包所在路径；（此步骤不确定是否必须有，如果默认就在此路径下执行命令，则不需要）
• sh restart.sh （需要将restart.sh文件放置在部署包所在路径下）

     shell脚本内容：杀死之前的进程；重新启动部署包进程；

6）jenkins配置自动部署机器：

位置：系统管理-系统配置-Publish over SSH

 Name：任意，后续在项目配置时可下拉选择此名称；

Hostname：服务器ip；

Username：服务器账号；

Remote Directory:服务器的根目录，任意目录，建议为“/”；这样在项目配置填写路径时只需填写绝对路径即可；

• 构建后操作，用于发邮件，可配置何时发邮件、何人发邮件、以及其他配置：Editable E-mail Notification

 

 Editable E-mail Notification

always：点击【Advanced Settings】--再点击【Add Trigger】--选择Always，根据情况配置；

如上图，将Always send to只保留了“Recipient List”,去掉了默认的“Developers”，将Failure-Any的“Developers”也删掉了（“Developers”不清楚在哪里配置）

“Recipient List”为上图红框部分；内容为 邮件接收人，多个邮件接收人，以空格分隔；

Project Recipient List：收件人列表采用默认配置，也可以自己主动配置

Project Reply-To List：项目恢复列表采用默认配置

Content Type：类型为默认HTML类型

Default Subject：默认标题模板，使用之前系统配置

Default Content：默认内容模板，使用之前系统配置

 

• 保存

点击页面最下方的“保存”，保存配置；

保存后即可进行构建，点击Build Now；

在工作区中下载部署包

 

其他问题：

1、sonar：

1、sonar为代码质量检查；

如果需要进行代码检查，则可以配置；

前端和后端都可以配置sonar代码检查，只要sonar支持的语言就可以，如java、JS、.net等；

2、运行 立即构建，构建项目的同时也会进行代码检查，检查结果同时显示在SonarQube中（服务部署在我司）

执行构建成功后，打开sonarqube的地址，即可看到代码检查结果。

 sonar相关非常全面的参考

sonarqube集成jenkins - 走看看

2、后端构建模式：

maven模式、ant模式、MSBuild模式、Dotnet模式

举例：maven模式、ant模式（P-spjys_OA）、MSBuild模式（P-GSGSXT）、Dotnet模式（P-AIOL）

回复：除maven外，MSBuild模式和Dotnet模式均针对.net平台，在我司构建并未成功，如果需要打包，需要再研究一下；

ant模式，目前也不用了；

遗留问题：

1、人防数据采集项目，未配置 限制运行节点，每次都会使用win_slave节点，而非win10节点；不理解为何；（类似的2个项目，也是同样配置，不限制节点，每次打包都是使用win_slave节点而非win10节点）

通过试验，发现选择如果特意选择win10节点，打包报错，报错内容 同xiaona笔记本电脑，为 依赖相关的报错；

如果特意选择win_slave节点则没有问题；