1 引言

1.1 编写目的

指导质量管理部，业务测试组同事进行Jenkins环境部署，通过Jenkins解决测试环境不可控，开发测试环境不一致等问题。

1.2 使用对象

质量管理部、基础研发部，集成部署部及EMT

目标受众：

本文的预期受众是从事持续交付或持续自动测试工作的软件工程师。要想按照本文中的步骤进行操作，您应该理解：

• 脚本开发。
• 软件开发流程。

1.3 持续集成概述

1.3.1 什么是持续集成

随着软件开发复杂度的不断提高，团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。尤其是近些年来，敏捷（Agile） 在软件工程领域越来越红火，如何能再不断变化的需求中快速适应和保证软件的质量也显得尤其的重要。

持续集成正是针对这一类问题的一种软件开发实践。它倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布和测试，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。

持续集成的核心价值在于：

1. 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；
2. 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能；
3. 持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。

1.3.2 持续集成的原则

业界普遍认同的持续集成的原则包括：

1）需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 IBM Rational ClearCase、CVS、Subversion 等；

2）开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地；

3）需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次；

4）必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。

1.3.3 持续集成系统的组成

一个完整的构建系统必须包括：

1. 一个自动构建过程，包括自动编译、分发、部署和测试等。
2. 一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。
3. 一个持续集成服务器。本文中介绍的 Jenkins 就是一个配置简单和使用方便的持续集成服务器。

1.4 Jenkins 简介

Jenkins 是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。

主要用于：

• 持续、自动地构建/测试软件项目。
• 监控一些定时执行的任务。

Jenkins拥有的特性包括：

• 易于安装-只要把jenkins.war部署到servlet容器，不需要数据库支持。
• 易于配置-所有配置都是通过其提供的web界面实现。
• 集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。
• 生成JUnit/TestNG测试报告。
• 分布式构建支持Jenkins能够让多台计算机一起构建/测试。
• 文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。
• 插件支持:支持扩展插件，您可以开发适合自己团队使用的工具。

部署一个CI系统的最低要求是，一个可获取源代码的仓库，一个包含构建脚本的项目。下图概括了CI系统的基本结构

图：CI系统的基本结构

2 Jenkins环境部署部署

2.1 Jenkins安装

2.1.1 Java -jar安装

1. 从Jenkins官网下载jenkins.war文件。官网地址:http://jenkins-ci.org/，注意选择最新版本的Long-Term Support Release
2. 运行 java -jar jenkins.war（可添加命令 --httpPort=$HTTP_PORT，用来设置jenkins运行时的web端口）
   注意：Jenkins 最新war包需要运行 Java 7以及以上的版本。

2.1.2 servlet 安装

.  1.从Jenkins官网下载jenkins.war文件。官网地址:http://jenkins-ci.org/，注意选择最新版本的Long-Term Support Release

2. 将下载的war包文件部署到 servlet 容器，然后启动容器，在浏览器的URL地址栏中输入类似http://localhost:8080/jenkins/这样的地址即可

2.2 Jenkins配置

2.2.1 系统管理

在已运行的Jenkins主页中，点击左侧的系统管理进入如下界面：

图：Jenkins系统管理

2.2.2 系统设置

在已运行的Jenkins主页中，点击左侧的系统管理 —> 系统设置进入如下界面：

图：系统设置页面

2.2.2.1  JDK、Maven，SVN配置

2.2.2.1.1 JDK,Maven配置

配置一个JDK、Maven实例，请在每一节下面单击Add(新增) 按钮，这里将添加实例的名称和绝对地址。

JDK别名：命名标示，可随意取名。建议同安装根目录名保持一致

JAVA_HOME：本机JDK的安装路径（绝对路劲）

自动安装：不推荐这个选项，会出现需要oracle用户名，VPN等要求

后面Maven的配置是一样的，JDK去oracle官网下载， Maven去apache官网下载

Ps：每个文本框后面都有个问号，点击问号就会出现帮助信息

下图描述了以上两个部分。
图：JDK配置界面

2.2.2.1.2 SVN配置

因为我们的SVN使用的1.8的客户端版本，所以需要对Jenkins的SVN插件进行升级。

l 点击系统管理 - > 管理插件。

图：插件管理视图

l 找到Subversion Plug-in插件，点击下载并安装。

l 下载插件，如下图，检测网络连接是用的google的地址，因为没有FQ，所以访问不到是正常的，但是不影响下载安装。
图：Subversion Plug-in下载安装界面

l 下载完成重启Jenkins

Subversion Plug-in插件安装完成后，在系统设置中找到对应模块：
图：SVN配置视图

Subversion Workspace Version：Subversion 的版本号，选择您对应的版本号就行了（1.8向下兼容）

2.2.2.2 邮件通知配置

l 配置发件人

System Admin e-mail address：Jenkins邮件发送地址。（必须配置，否则报错 ）

l 配置邮件通知
注意：SMTP认证邮箱必须与系统管理员邮件地址保持一致。
小技巧：可配置默认邮件后缀，以后您填写邮件地址只需要输出@之前内容就行了
图：邮件通知配置视图

2.2.3 Configure Global Security(安全设置)

在已运行的Jenkins主页中，点击左侧的系统管理—>Configure Global Security进入如下界面：

图：安全设置界面

设置如上图，保存后系统管理中就出现管理用户的选项。页面右上角也会出现登录/注册的选项。

2.2.4 管理用户设置

在右上角点击注册

图：用户注册界面

注册点击sign up按钮，提示您现在已经登录.返回首页. 登录后和匿名账号看到的首页有几点不同，如下图红框所示：

图：用户登录页面

2.2.5 管理插件设置

前文进行SVN配置时，已经接触了相关插件安装的内容。

Jenkins提供了大量的插件，插件管理器允许您安装新的插件，和更新您Jenkins服务器上的插件。管理者将连接到联机资料库，检索可用的和已更新的插件。如果您的Jenkins服务器 无法直接连接到外部资源，您可以从Jenkins网站上下载。点击“管理插件”进入插件安装界面。Jenkins的插件安装管理配置都很简单，通过web直接全能搞定。

插件管理界面如下图所示：

图：插件管理视图

它包含四个标签：

l 可更新:清单中列示了Jenkins为某些插件搜索到了可用的更新。列出的每个插件可以被选择并应用更新。

l 可选插件:清单中列示了可用于安装（而不是目前已安装的）的所有插件。列出的每个插件都可以被选择并安装。

l 已安装:清单中列示了已经安装的插件。

l 高级:允许您通过设定HTTP代理的方式使Jenkins与在线插件库建立连接。此外，还提供了一个上传设备，可以安装您在Jenkins以外已下载的那些插件。

各种Jenkins插件根据之前所记述的类型进行分门别类。可勾选任意想安装的Jenkins插件，到页面最下面有两个按钮“Install without restart” “Download now and install after restart”，根据需要点选提交开始安装。

安装后，所有插件以hpi作为后缀名放置在plugins文件夹下。如果是高级用户还可以自行开发插件方便具体项目使用。

注意：安装完成后需要重启Jenkins部署的容器。这样才能使用新装的插件。

2.3 监控

当任务一旦运行，您将会看到这个任务正在队列中的仪表板和当前工作主页上运行。这两种显示如下。

图：左图构建历史，右图构建执行列表

一旦构建完成后，完成后的任务将会有三个地方进行显示。

您可以在Jenkins的控制面板上看到它，如下图。

图：主页面项目列表

在上面展示的截图中，您将注意到有两个图标描述当前作业的状态。S栏目代表着“最新构建状态”，W栏目代表着“构建稳定性”。Jenkins使用这两个概念来介绍一个作业的总体状况：

构建状态:下图中分级符号概述了一个Job新近一次构建会产生的四种可能的状态： 

l Successful:完成构建，且被认为是稳定的。

l Unstable:完成构建，但被认为不稳定。

l Failed:构建失败。

l Disabled:构建已禁用。

图：构建状态界面

构建稳定性: 当一个Job中构建已完成并生成了一个未发布的目标构建，如果您准备评估此次构建的稳定性，Jenkins会基于一些后处理器任务为构建发 布一个稳健指数 (从0-100 )，这些任务一般以插件的方式实现。它们可能包括单元测试(JUnit)、覆盖率(Cobertura )和静态代码分 析(FindBugs)。分数越高，表明构建越稳定。下图中分级符号概述了稳定性的评分范围。任何构建作业的状态(总分100)低于80分就是不稳定的。
图：构建稳定性界面

您也可以在当前Job主界面上看到它，如下图左下部分

图：项目构建界面

当前作业主页上还包含了一些有趣的条目。左侧栏的链接主要控制Job的配置、删除作业、构建作业。右边部分的链接指向最新的项目报告和构件。

通过点击构建历史（Build History）中某个具体的构建链接，您就能跳转到Jenkins为这个构建实例而创建的构建主页上。如下图

图：构建历史界面

如果您想通过视图输出界面来监控当前任务的进展情况。您可以单击Console Output（控制台输出）。如果工作已完成，这将显示构建脚本产生的静态输出；如果作业仍然在运行中，Jenkins将不断刷新网页的内容，以便您可以看到它运行时的输出。如下图：

图：控制台输出界面

3 Jenkins内置环境变量

l BUILD_NUMBER， 唯一标识一次build。例如23； 

l BUILD_ID，基本上等同于BUILD_NUMBER，但是是字符串，例如2011-11-15_16-06-21；

l JOB_NAME， job的名字，例如AppScan_mall_essence_test；

l BUILD_TAG， 作用同BUILD_ID,BUILD_NUMBER,用来全局地唯一标识一此build，例如jenkins- AppScan_mall_essence_test-23；

l EXECUTOR_NUMBER， 例如0；

l NODE_NAME，slave的名字，例如Master；

l NODE_LABELS，slave的label，标识slave的用处，例如Android打包；

l JAVA_HOME， java的home目录，例如C:\Program Files\Java\jdk1.8.0_45；

l WORKSPACE，job的当前工作目录，例如c:\jenkins\workspace\ AppScan_mall_essence_test；

l HUDSON_URL = JENKINS_URL， jenkins的url，例如http:// AppScan_mall_essence_test:8000/ ；

l BUILD_URL，build的url 例如http://localhost:8000/job/ AppScan_mall_essence_test /23/；

l JOB_URL， job的url，例如http://localhost:8000/job/ AppScan_mall_essence_test /；

l SVN_REVISION，svn 的revison
注意：项目可配置多个SVN变量说明：
The Subversion SCM plugin exports the svn revisions and URLs of the build‘s subversion modules as environment variables. These are $SVN_REVISION_n and $SVN_URL_n, where n is the 1-based index of the module in the configuration.

For backwards compatibility if there‘s only a single module, its values are also exported as $SVN_REVISION and $SVN_URL.

4 Jenkins 其他配置

4.1 Slave配置

Jenkins有个很强大的功能：分布式构建，分布式构建能够让同一套代码在不同的环境(如：Windows和Linux系统)中编译、测试等。而且Jenkins构建的代码和产物最后自动拷贝到主节点。

注意：注意：如果节点主机上不存在JDK，Jenkins会去自动下载，但Oracle对程序自动下载做了限制，会导致下载失败，然后一直循环这个问题。

建议：所有Unix/Mac/Linux或者Windows机器的环境路径统一(如：JDK、Maven)，便于管理、不易出现奇葩问题。

Jenkins版本：1.6.20(不同版本的配置可能不同)

l 进入节点配置界面：系统管理→管理节点→新建节点(左上角)

图：Slave配置页面

l 节点名称：建议使用字母、数字或字母和数字的组合。最好见名知意。不建议使用标点符号和中文(中文命名没有问题，但Job中无法引用)

l Dumb Slave：新建一个节点

l 复制现有节点：从已存在的节点中复制一份配置(存在节点才会显示)

l 点击ok进入下一步配置
图:Slave 节点配置

l Name：节点名称

l Description：节点描述，支持中文

l # of executors：最大同时构建数量(根据机器的性能定，单颗四核cpu建议不要超过5)【必须为数字】

l Remote FS root：节点的根目录(注意：如果目录不存在，会自动创建目录。你必须对该目录有读写权限，不然会报错：hudson.util.IOException2: Failed to copy xxxx)

l Labels：标记(又叫做标签)用来对多节点分组,标记之间用空格分隔.例如‘refression java6‘将会把一个节点标记上 和‘java6‘.
举例来说,如果你有多个Windows系统的构建节点并且你的Job也需要在Windows系统上运行,那么你可以配置所有的Windows系统节点都标 记为‘windows‘, 然后把Job也标记为‘windows‘.这样的话你的Job就不会运行在除了Windows节点以外的其它节点之上了.

l 用法：尽可能的使用这个节点/只允许运行绑定到这台机器的Job(根据你的需求，二选一)

l Launch method：运行方式有四个选项。建议选择第1、2种方式配置。详细如下：

n 【推荐】Launch slave agents on Unix machines via SSH   在Unix(包括Linux)机器上通过SSH通道连接节点 (适用于Unix和Linux)

u Host：节点主机的ip地址

u Credentials：凭据(如果为空或者不可选择，请在系统管理→Manage Credentials中配置。Manage Credentials的配置非常简单，这里就不在描述了。Manage Credentials配置完成后，需刷新节点配置页面才会显示。)

u Port：端口默认22

u JavaPath：[可选]JDK路径，默认和master节点相同。路径必须指定到Java程序，如：/path/bin/java

u JVM Options：[可选]JVM可选参数

u Prefix Start Slave Command：[可选]不知道干什么用的参数

u Suffix Start Slave Command：[可选]不知道干什么用的参数

u Connection Timeout in Seconds：[可选]链接超时设置

u Maximum Number of Retries：[可选]失败重连数

u Seconds To Wait Between Retries：[可选]重连间隔时间

u 测试可以使用Unix命令，会自动拼接在[SSH] Starting slave process:[Prefix Start Slave Command] cd ‘/path‘ && /path/bin/java -jar slave.jar [Suffix Start Slave Command]

n 【推荐】Launch slave agents via Java Web Start   通过Java Web Start连接节点 (适用于所有支持Java程序的系统)

u Tunnel connection through：[可选]在端口转发这种情况下使用

u JVM options：[可选]JVM可选参数

u 这种方法的缺点：如果该节点宕机了，主节点无法自动重启它。

n Launch slave via execution of command on the Master  通过主节点的控制台连接节点

u Jenkins的开发者考虑到某些企业可能有N++ 个节点(N>=你猜!)。如果在界面配置，那么升级版本之类的操作会很麻烦。所以允许你使用shell脚本去配置管理节点(貌似很方便的样子)。具体的脚本需要你自己写。

u Launch command：Unix运行脚本的命令，如：sh aaa.sh

n 【不建议使用】Let Jenkins control this Windows slave as a Windows service   让Jenkins节点添加到Windows服务中

u 这个选项比Launch slave agents via Java Web Start添加为服务更加稳定(帮助文档描述)。采用这种运行方式，那么这个系统不能登录任何用户。这种配置方式是非常的麻烦和折腾。

u Administrator user name：域\管理员账号

u Password：密码

u Host：节点主机IP或者域名

u Run service as：

u Use Local System User：使用本地系统用户

u Log on using a different account：使用不同的用户登录

u User name：账号

u Password：密码

u Use Administrator account given above：使用上面的用户登录

u Path to java executable：[可选]JDK路径。必须指定到Java程序,如：C:\Windows\system32\java.exe

u JVM options：[可选]JVM可选参数

l Availability：

u Keep this slave on-line as much as possible：尽可能保持节点在线【推荐】

u Take this slave on-line according to a schedule：根据时间表在线(类似于Linux的定时任务)

l Startup Schedule：类似于Linux定时任务的时间，如下：

l # every fifteen minutes (perhaps at :07, :22, :37, :52)

l H/15 * * * *

l # every ten minutes in the first half of every hour (three times, perhaps at :04, :14, :24)

l H(0-29)/10 * * * *

l # once every two hours every weekday (perhaps at 10:38 AM, 12:38 PM, 2:38 PM, 4:38 PM)

l H 9-16/2 * * 1-5

l # once a day on the 1st and 15th of every month except December

l H H 1,15 1-11 *

l 如果使用 H Jenkins会自动提前一段时间连接节点，避免出现同一时间高并发的问题

l Scheduled Uptime：超过任务时间后延迟多少分钟离线。如果此数值大于在线总时间(单位：分)，就会一直保持在线【必须为数字】

l Keep on-line while jobs are running：当有Job在构建时(到达离线时间了)继续保持在线

u Take this slave on-line when in demand and off-line when idle：让Jenkins根据需求自动连接或者离线

l In demand delay：告诉Jenkins如果有Job需要在此节点构建，需要在任务队列等待多长时间才会进入任务状态进行构建【必须为数字】

l Idle delay：告诉Jenkins多少分钟内如果没有Job需要构建就离线【必须为数字】

l Node Properties：

u Environment variables:配置环境变量(可以在脚本中引用)

u Tool Locations：工具的目录【推荐】。说明：可以替换系统设置的各种工具目录。如：JDK目录、Ant目录、Maven目录等。好处就是在不更改Job配置的情况下，不同环境(如：Windows和Linux) Job配置通用。

4.1.1 Windows Slave

4.1.1.1 Launch slave agents via Java Web Start

相应配置选择完成后，进入需要控制的远程机器上，一定要进入远程的slave机器，而不是你的master机器。输入对应的你的jenkins的地址，例如这里：

http://192.168.11.237:8080/computer/

点击进入对应的该slave机器的图标进入：

图：Launch slave agents via Java Web Start配置完成界面

如上图所示，有两种方式可以启动节点(都是JNLP方式。JNLP连接需要端口，默认连接端口是随机的，端口更改 系统设置→Configure Global Security→JNLP节点代理的TCP端口)

你以下几种方式启动：

l Launch agent from browser on slave  下载文件slave-agent.jnlp文件，双击打开。

n 一般用在Windows系统上，需要javaws.exe(在Java的bin目录中可以找到)程序才能打开。如果提示错误，请卸载JDK后重新安装。

u 注意事项：

u 确认slave-agent.jnlp 是用javaws来运行的，而不是java.exe 或者是javaw.exe来运行，因为一般的机器默认是采用java.exe启动的。

u 将slave-agent.jnlp用notepad打开后，确认其中的URL是可用的Jenkins地址。其中的配置可能是这样的：

确认其中的url地址是正确的地址,而不是localhost或者127.0.0.1。

以上的配置完成后，如果点击lanch按钮，可能会报一下的错误：

Slave irshost12.tc.tb.com

Connection was broken

java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(SocketInputStream.java:168)

at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

at java.io.BufferedInputStream.read(BufferedInputStream.java:237)

at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2252)

at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2545)

at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2555)

at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1294)

at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)

at hudson.remoting.Command.readFrom(Command.java:92)

at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:72)

at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)

Connect slave to Jenkins one of these ways:

 Launch agent from browser on slave

Run from slave command line:

javaws http://16.158.69.53:9999/jenkins/computer/irshost12.tc.com.com/slave-agent.jnlp

Or if the slave is headless:

java -jar slave.jar -jnlpUrl http://16.158.69.53:9999/jenkins/computer/irshost12.tc.com/slave-agent.jnlp

如果出现上面的问题，我们就不要在点击launch按钮起启动了，采用命令行去启动也是一样的，这个时候选择下面的启动方式

l Run from slave command line
1.javaws  http://xxxx/slave-agent.jnlp  
如果你配置了权限那么后面还有一串看不懂的随机Key

n 下载slave.jar到本地，然后进入存放slave.jar的目录，复制粘贴并运行 java -jar slave.jar -jnlpUrl http://xxxxx  即可启动。

l Or if the slave is headless:
java -jar slave.jar -jnlpUrl http://192.168.11.237:8080//computer/192.168.11.155_WIN7_ICE/slave-agent.jnlp

如果启动成功，成功启动如下图所示：

图：windows Slave Launch slave agents via Java Web Start 节点连接

点击左上角的File选择Install as a service就可以添加为Windows的服务了(默认开机自动启动)。将当前的slave设置成一个服务，每次机器重启的时候都自动启动slave服务，这样就不用每次都去启动这个slave agent了。

注意：

如果上面的窗口中显示Connected，可是一会有出现了Terminated的状态，那么很可能是因为你的jenkins配置权限的时候没有给匿名用户启动slave的权限。

具体操作是进入jenkins主界面，然后进入Manage Jenkins -> Configure Global Security ，勾选其中的anonymous用户的slave部分的权限。

图：anonymous Slave 启动权限配置界面

4.1.1.2 Let Jenkins control this Windows slave as a Windows service

这种启动方式比较繁琐，此处不做赘述，可参考：http://blog.sina.com.cn/s/blog_87f0f17e0101iq8a.html

4.1.2 MAC/Linux Slave（待添加）

4.1.2.1 Launch slave agents on Unix machines via SSH

l 在jenkins上增加节点
图：Jenkins增加节点配置界面

l 在Mac系统中将ssh的服务打开，在偏好设置-互联网与无线 -共享中
图：互联网与无线配置界面

l 使用mac root用户修改sshd-config的鉴权方式
首先获取到root用户登录，然后vi /etc/ssd_config，修改PasswordAuthentication no 为PasswordAuthentication yes

l 此时在jenkins节点中点击salve节点，Lauch。

注意：

1.Slave节点机器上必须配置好java环境，建议手工在Environment variables指定JAVA_HOME路径信息
图：Environment variables JAVA_HOME配置

2.命令行调用code sign时报错：User interaction is not allowed

n 网上找了一些命令来用:

$security list-keychains

$unlock-keychain "-p" "keychainpassword"  "/Users/bixiaopeng/Library/Keychains/login.keychain”

但无法解决

于是乎用下面的方法解决了：

1.在应用程序里搜索Keychain Access，中文叫钥匙串访问权限

2.找到你的证书，右击 — 显示简介 — 访问控制 — 选中【允许所有应用程序访问此项目】 — 存储更攺 — 输入密码后保存更攺，解决问题。

n 如果上面的都无法解决，那就使用jenkins的Xcode插件吧
图：Xcode配置界面

除了以上的连接方式，也可以采用私钥的形式进行链接：SSH Username with private key

这种启动方式比较繁琐，此处不做赘述，可参考：http://blog.sina.com.cn/s/blog_87f0f17e0101iq8a.html

4.2 Manage and Assign Roles配置

Jenkins的默认权限控制过于简单，用户进行管理配置这块推荐使用“Role-based Authorization Strategy”

4.2.1 Role-based Authorization Strategy安装

点击“系统管理”- > “管理插件” 进入插件安装界面，按照上文“管理插件设置”选择Role-based Authorization Strategy进行安装

4.2.2 “Role-based Authorization Strategy”的启用

点击“系统管理”点击“系统设置”，如下图所示：“授权策略”选择使用“Role-Based Strategy”。

配置完成save后在“系统管理”下新增选项“Manage and Assign Roles”。点击“管理用户”新建账户后即可进行账户，群组的安全策略配置。

图：Role-Based Strategy配置界面

4.2.3 管理组权限设置，构建权限设置：

点击“Manage and AssignRoles”，先选择“Manage Roles”如下图所示，在Global roles这里创建权限分组，如admin是最高管理员权限，拥有所有权限，guest只有读权限等，这里可以根据具体情况设置多个分组，不同权限；然后设置“Project roles”，Role to add 填写分组名称，Pattern填写分组的规则。例如这个分组叫TEST，他的规则就是构建名为“TEST.*”的所有构件，然后在“Job”区里勾选相关权限。设置完成点保存即可。

图：Global roles设置界面

图：Project roles设置界面

4.2.4 用户权限分配

点击“Assign Roles”如下图所示，在“Global roles”下“User/group to add”栏中输入添加的用户名，然后勾选管理组。记得把默认的匿名用户“Anonymous”的默认admin权限去掉，在添加管理员之后，否则不需登录就能控制整个Jenkins的权限；在“Project roles”下“User/group to add”栏中输入添加的用户名，然后勾选对应构建权限名。设置完保存即可。

图：Assign Roles配置界面

4.3 E-mail Notification配置

Jenkins默认提供了一个邮件通知，能在构建失败、构建不稳定等状态后发送邮件。但是它本身有很多局限性，比如它的邮件通知无法提供详细的邮件内容、无法定义发送邮件的格式、无法定义灵活的邮件接收配置等等。在这样的情况下，我们找到了Jenkins Email Extension Plugin。该插件能允许您自定义邮件通知的方方面面，比如在发送邮件时您可以自定义发送给谁，发送具体什么内容等等。

4.3.1 配置

E-mail Notification配置包含两个部分：全局配置和项目配置。

4.3.2 全局配置

在一个项目中应用E-mail Notification插件之前，您必须做一些全局的配置。现在先跳转到Jenkins的“系统设置”页面。

找到标题为“Extended E-mail Notification”的片段，你就能配置一些全局的E-mail Notification属性。这些属性必须匹配你SMTP邮件服务器的设置。这一节不仅能配置成Jenkins原有邮件通知的镜像(虽然有很多配置是一样的，但这是个不同的扩展点)，而且还增加了一些额外的功能。输入框中名为 Default Subject 和 Default Content 的项允许你在全局级别配置邮件的内容。这样做的话，可以使您为所有的项目按您的需求做更好的、更简单的配置。如下图。
图：Extended E-mail Notification配置

释放默认配置：

Default Subject：构建通知:$PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS!

Maximum Attachment Size：20

Default Content：

(本邮件是程序自动下发的，请勿回复！)

项目名称：$PROJECT_NAME

构建编号：$BUILD_NUMBER

SVN版本号：${SVN_REVISION}

构建状态：$BUILD_STATUS

触发原因：${CAUSE}

构建日志地址：${BUILD_URL}

构建地址： $BUILD_URL

APP文件下载地址(Android/IOS)：${JOB_URL}ws/version/

变更集: ${JELLY_SCRIPT,template="text"}

$PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS:

Check console output at $BUILD_URL to view the results.

4.3.2.1 E-mail Notification全局属性详解

E-mail Notification全局属性详解：

l Override Global Settings：如果不选，该插件将使用默认的E-mail Notification通知选项。反之，您可以通过指定不同于( 默认选项)的设置来进行覆盖。

l Default Content Type：指定构建后发送邮件内容的类型，有Text和HTML两种.

l Use List-ID Email Header：为所有的邮件设置一个List-ID的邮件信头，这样你就可以在邮件客户端使用过滤。它也能阻止邮件发件人大部分的自动回复(诸如离开办公室、休假等等)。你可以使用你习惯的任何名称或者ID号，但是他们必须符合如下其中一种格式(真实的ID必须要包含在<和>标记里)：

<ci-notifications.company.org>

Build Notifications <ci-notifications.company.org>

“Build Notifications” <ci-notifications.company.org>

l Add ‘Precedence: bulk‘ Email Header：设置优先级.

l Default Recipients：自定义默认电子邮件收件人列表。如果没有被项目配置覆盖,该插件会使用这个列表。您可以在项目配置使用$ DEFAULT_RECIPIENTS参数包括此默认列表，以及添加新的地址在项目级别。添加抄送：cc:电子邮件地址例如,CC:someone@somewhere.com

l Reply To List：回复列表, A comma separated list of e-mail addresses to use in the Reply-To header of the email. This value will be available as $DEFAULT_REPLYTO in the project configuration.

l Emergency reroute：如果这个字段不为空，所有的电子邮件将被单独发送到该地址（或地址列表）。

l Excluded Recipients：防止邮件被邮件系统认为是垃圾邮件,邮件列表应该没有扩展的账户名(如:@domain.com),并且使用逗号分隔

l Default Subject：自定义邮件通知的默认主题名称。该选项能在邮件的主题字段中替换一些参数，这样你就可以在构建中包含指定的输出信息。

l Maximum Attachment Size：邮件最大附件大小。

l Default Content：自定义邮件通知的默认内容主体。该选项能在邮件的内容中替换一些参数，这样你就可以在构建中包含指定的输出信息。

l Default Pre-send Script：默认发送前执行的脚本。

l Enable Debug Mode：启用插件的调试模式。这将增加额外的日志输出，构建日志以及Jenkins的日志。在调试时是有用的，但不能用于生产。

l Enable Security：启用时，会禁用发送脚本的能力，直接进入Jenkins实例。如果用户试图访问Jenkins管理对象实例，将抛出一个安全异常。

l Content Token Reference：邮件中可以使用的变量，所有的变量都是可选的。

4.3.2.2 全局邮件变量

E-mail Notification插件允许使用变量来动态插入数据到邮件的主题和内容主体中。变量是一个以$(美元符号)开始，并以空格结束的字符串。当一个邮件触发时，主题和内容主体字段的所有变量都会通过真实的值动态地替换。同样，变量中的“值”能包含其它的变量，都将被替换成真实的内容。

比如，项目配置页的默认主题和内容分别对应的是全局配置页面的DEFAULT_SUBJECT和DEFAULT_CONTENT，因此它会自动地使用全局的配置。同理，触发器中的Subject和Content分别对应的是项目配置页面的DEFAULT_SUBJECT和DEFAULT_CONTENT，所以它也会自动地使用项目的配置。由于变量中的“值”能包含其它的变量，所以就能为变量快速地创建不同的切入点：全局级别(所有项目)，专属级别(单一项目)，触发器级别(构建结果)。

如果你要查看所有可用的变量，你可以点击配置页的Content Token Reference的问号获取详细的信息。

所有的变量都是可选的，每个变量可以如下表示，字符串类型使用name=“value”，而布尔型和数字型使用name=value。如果{和}标记里面没有变量，则不会被解析。示例：$TOKEN,${TOKEN},${TOKEN,count=100},${ENV,var=”PATH”}

提示：用英文逗号分隔变量的参数。

一些常用的属性：

l ${FILE,path="PATH"} 包括指定文件（路径）的含量相对于工作空间根目录。

n path文件路径，注意：是工作区目录的相对路径。

l ${BUILD_NUMBER} 显示当前构建的编号。

l ${JOB_DESCRIPTION} 显示项目描述。

l ${SVN_REVISION} 显示svn版本号。还支持Subversion插件出口的SVN_REVISION_n版本。

l ${CAUSE} 显示谁、通过什么渠道触发这次构建。

l ${CHANGES } -显示上一次构建之后的变化。

n showPaths 如果为 true,显示提交修改后的地址。默认false。

n showDependencies 如果为true，显示项目构建依赖。默认为false

n format 遍历提交信息，一个包含%X的字符串，其中%a表示作者，%d表示日期，%m表示消息，%p表示路径，%r表示版本。注意，并不是所有的版本系统都支持%d和%r。如果指定showPaths将被忽略。默认“[%a] %m\\n”。

n pathFormat 一个包含“%p”的字符串，用来标示怎么打印路径。

l ${BUILD_ID}显示当前构建生成的ID。

l ${PROJECT_NAME} 显示项目的全名。（见AbstractProject.getFullDisplayName）

l ${PROJECT_DISPLAY_NAME} 显示项目的显示名称。（见AbstractProject.getDisplayName）

l ${SCRIPT} 从一个脚本生成自定义消息内容。自定义脚本应该放在"$JENKINS_HOME/email-templates"。当使用自定义脚本时会默认搜索$JENKINS_HOME/email-templatesdirectory目录。其他的目录将不会被搜索。

n script 当其使用的时候，仅仅只有最后一个值会被脚本使用（不能同时使用script和template）。

n template常规的simpletemplateengine格式模板。

l ${JENKINS_URL} 显示Jenkins服务器的url地址（你可以再系统配置页更改）。

l ${BUILD_LOG_MULTILINE_REGEX}按正则表达式匹配并显示构建日志。

n regex java.util.regex.Pattern 生成正则表达式匹配的构建日志。无默认值，可为空。

n maxMatches 匹配的最大数量。如果为0，将匹配所有。默认为0。

n showTruncatedLines 如果为true，包含[...truncated ### lines...]行。默认为true。

n substText 如果非空，就把这部分文字（而不是整行）插入该邮件。默认为空。

n escapeHtml 如果为true，格式化HTML。默认为false。

n matchedSegmentHtmlStyle 如果非空，输出HTML。匹配的行数将变为<b style=”your-style-value”> html escaped matched line </b>格式。默认为空。

l ${BUILD_LOG} 显示最终构建日志。

n maxLines 日志最多显示的行数，默认250行。

n escapeHtml 如果为true，格式化HTML。默认false。

l ${PROJECT_URL} 显示项目的URL地址。

l ${BUILD_STATUS} -显示当前构建的状态(失败、成功等等)

l ${BUILD_URL} -显示当前构建的URL地址。

l ${CHANGES_SINCE_LAST_SUCCESS} -显示上一次成功构建之后的变化。

n reverse在顶部标示新近的构建。默认false。

n format遍历构建信息，一个包含%X的字符串，其中%c为所有的改变，%n为构建编号。默认”Changes for Build #%n\n%c\n”。

n showPaths,changesFormat,pathFormat分别定义如${CHANGES}的showPaths、format和pathFormat参数。

l ${CHANGES_SINCE_LAST_UNSTABLE} -显示显示上一次不稳固或者成功的构建之后的变化。

n reverse在顶部标示新近的构建。默认false。

n format遍历构建信息，一个包含%X的字符串，其中%c为所有的改变，%n为构建编号。默认”Changes for Build #%n\n%c\n”。

n showPaths,changesFormat,pathFormat分别定义如${CHANGES}的showPaths、format和pathFormat参数。

l ${ENV} –显示一个环境变量。

n var– 显示该环境变量的名称。如果为空，显示所有，默认为空。

l ${FAILED_TESTS} -如果有失败的测试，显示这些失败的单元测试信息。

l ${JENKINS_URL} -显示Jenkins服务器的地址。(你能在“系统配置”页改变它)。

l ${HUDSON_URL} -不推荐，请使用$JENKINS_URL

l ${PROJECT_URL} -显示项目的URL。

l ${SVN_REVISION} -显示SVN的版本号。

l ${JELLY_SCRIPT} -从一个Jelly脚本模板中自定义消息内容。有两种模板可供配置：HTML和TEXT。你可以在$JENKINS_HOME/email-templates下自定义替换它。当使用自动义模板时，”template”参数的名称不包含“.jelly”。

n template模板名称，默认”html”。

l ${TEST_COUNTS} -显示测试的数量。

n var– 默认“total”。

u total -所有测试的数量。

u fail -失败测试的数量。

u skip -跳过测试的数量。

4.3.3 项目配置

要想在一个项目中使用email-ext插件，你首先必须在项目配置页激活它。在构建后操作——“增加构建后操作步骤”选项中勾选”Editable Email Notification”标签。

图：E-mail Notification项目配置界面

4.3.3.1 项目基本配置

当插件激活后你就能编辑如下字段（只列出常用的字段）：

l Project Recipient List：这是一个以逗号(或者空格)分隔的收件人邮件的邮箱地址列表。允许您为每封邮件指定单独的列表。
Ps：如果你想在默认收件人的基础上添加收件人：$DEFAULT_RECIPIENTS,<新的收件人>

n Default Subject：允许你配置此项目邮件的主题。

n Default Content：跟Default Subject的作用一样，但是是替换邮件内容。

n Attach Build Log：附件构建日志。

u Compress Build Log before sending：发送前压缩生成日志（zip格式）。

4.3.3.2 项目高级配置

要查看插件的高级配置，请点击“ Advanced Settings...”按钮。该选项允许您各种类型的邮件触发器指定接收者。默认情况下，是没有配置的触发器，所以默认情况下不会发送邮件。要增加更多的触发器，选择“Add a Trigger”旁边下拉列表中的类型，它会增加到控件上面的列表中。

配置说明：

l Send to Recipient List：如果勾选，邮件将发送到”Project Recipient List”中的所有邮件地址。

l Send to Committers：该邮件会发给上次构建时检查过代码的人员，该插件会基于提交者的ID和追加Jenkins配置页面的(default email suffix)默认邮件后缀来生成一个邮件地址。譬如，上次提交代码的人是”first.last”， 默认的电子邮件后缀为“@somewhere.com”，那么电子邮件将被发送到“first.last@ somewhere.com”。

l Send To Requester：如果勾选，邮件将发送给构建触发者。

l Include Culprits：如果勾选，而且 “Send To Committers”勾选，邮件将包含最后成功构建的提交者。

l More Configuration：通过单击”+(expand)”链接您能为每个邮件触发器作更多单独的设置。

n Recipient List：这是一个以逗号(或者空格)分隔的可接受邮件的邮箱地址列表。如果触发就发送邮件到该列表。该列表会追加在”Global Recipient List”里。

n Subject：指定选择邮件的主题。注意：高级选项中的邮件触发器类型可覆盖对它的配置。

n Content：指定选择邮件的内容主体。注意：高级选项中的邮件触发器类型可覆盖对它的配置。

l Remove通过单击指定触发器当前行的“Delete”按钮，你可以删除该触发器。

4.3.3.3 触发器类型

配置发送需首先确定触发器
注意：所有的触发器都只能配置一次

l Failure：即时发送构建失败的邮件。如果”Still Failing”触发器已配置，而上一次构建的状态是”Failure”，那么”Still Failing”触发器将发送一封邮件来替代(它)。

l Unstable：即时发送构建不稳固的邮件。如果”Still Unstable”触发器已配置，而上一次构建的状态是”Unstable”，那么”Still Unstable”触发器将发送一封邮件来替代(它)。

l Still Failing：如果两次或两次以上连续构建的状态为”Failure”，发送该邮件。

l Success：如果构建的状态为”Successful”发送邮件。如果”Fixed”已配置，而上次构建的状态为“Failure”或“Unstable”，那么”Fixed”触发器将发送一封邮件来替代(它)。

l Fixed：当构建状态从“Failure”或“Unstable”变为”Successful”时发送邮件。

l Still Unstable：如果两次或两次以上连续构建的状态为” Unstable “，发送该邮件。

l Before Build：当构建开始时发送邮件。

4.3.3.4 项目邮件变量

注意：这里只解释全局配置页面中缺少的变量。

l ${DEFAULT_SUBJECT}：这是Jenkins系统配置页面默认配置的邮件主题

l ${DEFAULT_CONTENT}：这是Jenkins系统配置页面默认配置的邮件内容主体

l ${PROJECT_DEFAULT_SUBJECT}：这是项目的默认邮件主题。高级配置中使用该令牌的结果要优先于Default Subject字段。警告：不要在Default Subject 或者Default Content中使用该令牌，它会产生一个未知的结果。

l ${PROJECT_DEFAULT_CONTENT}：这是项目的默认邮件内容主体。高级配置中使用该令牌的结果要优先于Default Content字段。警告：不要在Default Subject 或者Default Content中使用该令牌，它会产生一个未知的结果。

4.3.4 E-mail Notification邮件效果展示

图：E-mail Notification邮件效果图

5 Jenkins 使用流程

持续交付需要快速且自动地部署各种更改集。完成部署或交付工作需要多个步骤。标准的流程是：

• 开发人员交付各种更改
• 源代码控制工具进行构建工作
• 运行自动的测试工作
• 安装构建内容

6 Jenkins框架的部署拓扑结构（当前）

l 开发部署：开发人员向诸如 Subversion(SVN)等的源代码控制服务器提交更改集

l 持续集成：添加 Jenkins 以后，会有一个 Jenkins 主机器。Subversion构建工具包已安装在该服务器上。Jenkins使用该构建工具包并通过 Subversion下载源代码，同时触发构建工具包生成构建版本。所有的项目都在在 Jenkins 主机器上进行管理。Android打包，AppScan扫描，Web项目开发环境发布在Jenkins master机器上运行，IOS打包（192.168.1.90_Darwin_IOS）作为Jenkins 从机器提供服务。它们由 Jenkins 主机器控制，并运行安装项目。

图.Jenkins框架的部署拓扑结构

基于jenkins搭建一个持续集成服务器