3.8 小结 

Hello World项目中有一些Maven的约定：在项目的根目录中放置pom.xml，在src/main/java目录中放置项目的主代码，在src/test/java中放置项目的测试代码。之所以一步一步地展示这些步骤，是为了能让可能是Maven初学者的你得到最实际的感受。我们称这些基本的目录结构和pom.xml文件内容称为项目的骨架，当第一次创建项目骨架的时候，你还会饶有兴趣地去体会这些默认约定背后的思想，第二次，第三次，你也许还会满意自己的熟练程度，但第四、第五次做同样的事情，你可能就会恼火了。为此Maven提供了Archetype以帮助我们快速勾勒出项目骨架。

还是以Hello World为例，我们使用maven archetype来创建该项目的骨架，离开当前的Maven项目目录。

如果是Maven 3，简单地运行：

mvn archetype:generate 

如果是Maven 2，最好运行如下命令：

mvn org.apache.maven.plugins:mavenarchetype
plugin:2.0alpha5:generate  

很多资料会让你直接使用更为简单的 mvn archetype:generate 命令，但在Maven 2中这是不安全的，因为该命令没有指定Archetype插件的版本，于是Maven会自动去下载最新的版本，进而可能得到不稳定的SNAPSHOT版本，导致运行失败。然而在Maven 3中，即使用户没有指定版本，Maven也只会解析最新的稳定版本，因此这是安全的。具体内容见7.7节。

我们实际上是在运行插件mavenarchetypeplugin，注意冒号的分隔，其格式为 groupId:artifactId:version:goal，org.apache.maven.plugins 是maven官方插件的groupId，mavenarchetypeplugin 是Archetype插件的artifactId，2.0alpha5 是目前该插件最新的稳定版，generate是要使用的插件目标。

紧接着会看到一段长长的输出，有很多可用的Archetype供选择，包括著名的Appfuse项目的Archetype、JPA项目的Archetype等。每一个Archetype前面都会对应有一个编号，同时命令行会提示一个默认的编号，其对应的Archetype为mavenarchetypequickstart，直接回车以选择该Archetype，紧接着Maven会提示输入要创建项目的groupId、artifactId、version以及包名package。如下输入并确认：

Define value for groupId: : com.juvenxu.mvnbook  
Define value for artifactId: : helloworld  
Define value for version:  1.0SNAPSHOT: :  
Define value for package:  com.juvenxu.mvnbook: : 
com.juvenxu.mvnbook.helloworld  
Confirm properties configuration:  
groupId: com.juvenxu.mvnbook  
artifactId: helloworld  
version: 1.0SNAPSHOT  
package: com.juvenxu.mvnbook.helloworld 
Y: : YArchetype

什么是持续集成

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

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

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

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

持续集成的原则

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

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

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

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

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

持续集成系统的组成

由此可见，一个完整的构建系统必须包括：

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

回页首

Jenkins 简介

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

Jenkins 的安装非常简单，只需要从 Jenkins 的主页上下载最新的 jenkins.war 文件然后运行 java -jar jenkins.war。同时，还可以点击 Jenkins 页面上的 launch 按钮完成下载和运行 Jenkins。

图 1. Jenkins Launch 按钮

启动 Jenkins 后，会有一个后台进程在命令行模式下运行。此时在浏览器地址栏中打开 http://localhost:8080 就可以看到 Jenkins 的页面了。Jenkins 的可贵之处在于具有非常高的可用性，从它的界面中能很轻松地完成各种配置，更多的配置和使用信息，可以在 Jenkins 的官方网站上查询。

图 2. 命令行模式下运行 Jenkins

图 3. Jenkins 主界面

非常有趣的是，Jenkins 还提供了非常丰富的插件支持，这使得 Jenkins 变得越来越强大。我们可以方便的安装各种第三方插件，从而方便快捷的集成第三方的应用。比如 Jenkins 提供了对于 IBM Rational ClearCase 的插件支持。

图 4. Jenkins 可以集成 ClearCase 插件

此外，Jenkins 提供了丰富的管理和配置的功能，包括系统配置、管理插件、查看系统信息、系统日志、节点管理、Jenkins 命令行窗口、信息统计等功能。试试看，您就会发现 Jenkins 非常好上手使用。

图 5. Jenkins 提供了丰富的管理功能

回页首

基于 Jenkins 快速搭建持续集成环境

正如前文中所描述的那样，一个持续集成环境需要包括三个方面要素：代码存储库、构建过程和持续集成服务器。对 Jenkins 有了初步了解后，我们通过一个实例来集中展示如何快速搭建一个简单的基于 Jenkins 的持续集成环境。

假设我们使用的代码存储库是 IBM Rational ClearCase。Jenkins 提供了对 ClearCase 的插件支持，它能方便地让我们连接到 Base ClearCase 或者 UCM ClearCase，使其成为 Jenkins Project 的代码控制器。另外，这个插件是基于 cleartool 命令的，所以必须在 Jenkins 的持续集成服务器上安装 ClearCase 的客户端程序。

在 Jenkins 的插件管理界面中选择 ClearCase Plugin，点击页面下方的 Install 按钮。

图 6. 选择 ClearCase 插件

在打开的页面中提示安装完成后，Jenkins 需要重新启动来激活这个插件。重新执行 java -jar Jenkins.war 后，在 Jenkins 的页面中，我们就能看到 ClearCase plugin 已经被安装到 Jenkins 了。

图 7. ClearCase 插件安装成功

类似 IBM Rational ClearCase，SVN（subversion）是目前比较流行的版本管理工具。很多开源软件都是用 SVN 作为代码版本管理软件。为了让实例更具有代表性，本文中我们使用 SVN 作为代码存储器。

接下来，我们开始新建一个 Jenkins 项目， 由于我们需要连接 SVN 的代码存储器， 我们选择 Build a free-style software project。

图 8. 新建 JenkinsTest Job

然后我们就可以很方便的配置这个 JenkinsTest 项目了。Jenkins 很人性化的一点是在每个配置项的右侧都有一个帮助的图标，点击这个图标，Jenkins 会告诉您如何配置这个配置项。

图 9. 配置 JenkinsTest

根据实际的 SVN 服务器服务器信息配置 Source Code Management，这能让 Jenkins 知道如何从哪里获取最新的代码。本例中假设 Repository 就在本地。

图 10. 配置连接到 SVN 服务器

根据开发需要，假设每一个小时我们需要重新构建一次。选择 Build periodically，在 Schedule 中填写 0 * * * *。

第一个参数代表的是分钟 minute，取值 0~59；

第二个参数代表的是小时 hour，取值 0~23；

第三个参数代表的是天 day，取值 1~31；

第四个参数代表的是月 month，取值 1~12；

最后一个参数代表的是星期 week，取值 0~7，0 和 7 都是表示星期天。

所以 0 * * * * 表示的就是每个小时的第 0 分钟执行一次构建。

图 11. 选择如何触发构建

接下来就是要添加 build 的步骤了。Jenkins 提供了四个选项供我们选择，可以根据需要执行或调用外部命令和脚本。

图 12. 四种 build step 供选择

在本例中，我们通过调用和执行 Windows batch command，将 SVN repository 中 Java 代码编译并生成 Jar 文件。也可以根据项目的实际编写自己的 shell 脚本配置在这里。

图 13. 配置 Execute Windows batch command

选择和配置其他的选项，比如邮件提醒，然后点击 save 保存。

图 14. 配置邮件提醒

接下来的每小时的第 0 分钟，JenkinsTest Job 就会被构建。我们可以在 Jenkins 中观察构建的进度和最终的状态——成功或者失败。太阳代表之前的构建没有任何失败，蓝色的小球代表构建成功。

图 15. JenkinsTest 开始构建

同时我们可以点击 JenkinsTest 查看单次构建的 Console 的输出结果。从中我们能看到构建的第一步是从 SVN 服务器上 check out 代码，然后调用我们先前配置的 Windows batch command。

图 16. JenkinsTest 构建的 console 输出

最后，我们可以看到 build 的最后结果 Success，表明本次构建成功。

图 17. 构建成功的 Console 输出

接下来我们再次新建一个 Jenkins 的 Job，用于将生成的 build 分发到不同的节点上。这次 build triggers 我们选择 Build after other projects are built，让这个 Job 在 JenkinsTest 成功 build 后触发。这样一来就能达到我们自动 build 和自动分发的功能。

图 18. 新建 Distribute job

不同的是，这次我们选择调用 Ant 脚本来完成分发的工作。只需要将 Ant 脚本的 XML 的文件配置在 Targets 中供 Jenkins 调用。

图 19. Distribute 调用外部 Ant 脚本

然后我们就可以在 Jenkins 中观察构建的状态了。一旦构建失败我们能看到相应的警示图标，同时，如果配置了邮件提醒，相关人员也会受到邮件。记住我们先前所提醒的那样，分析和处理构建的失败是优先级最高的工作。接下来，我们还可以加入更多的 Jenkins 项目来实现自动化测试等功能，让持续集成更方便有效地服务于项目开发。

图 20. 查看持续集成状态

回页首

结束语

本文简单介绍了持续集成的概念并着重介绍了如何基于 Jenkins 快速构建持续集成环境。通过具体实例的描述，相信读者对 Jenkins 的基本功能和实现方法有个更清楚地认识和理解。其实，Jenkins 的功能远不至文中所述的这些，Jenkins 还有详尽的日志处理和持续集成构建状态的分析等功能。希望在进一步的学习和应用中与大家分享。

enkins有一些专用术语，请参考下面的连接：

https://wiki.jenkins-ci.org/display/JENKINS/Terminology

1.通过Jenkins web页面添加Git plugin

Manage Jenkins->Manage Plugins->Available中选择Git Plugin安装，

注意要填写user name和 email地址，否则日后会碰到git tag的错误

2.在Jenkins使用的机器上创建Git用户所需要的公钥

具体步骤参考前面Git server文章

http://blog.csdn.net/sheismylife/article/details/7204345

但是注意，要将最后生成的.ssh目录下的公钥和私钥文件复制到/var/lib/jenkins/.ssh目录下，否则git clone命令会报错

3.修改jenkins目录权限

chmod -R 777 /var/lib/jenkins

4.现在可以通过web页面创建一个项目Test，然后设置该项目使用Git作为版本管理。

并且设置repository路径，比如我的：git@S1:cml.git

5.在build选项的pom文件指定你需要执行的pom.xml路径

比如我的一个测试工程名叫client，是个maven工程，我设置为client/pom.xml

6.现在可以点击左侧的Build now进行测试

一切OK,则没有错误日志。在Build History中可以看到测试结果，有没有错误。

7.Email发送设置

在Manage Jenkins->Configure System->Email Notification中，设置SMTP发送的基本信息，点击Advanced，可以填写用户名和密码。还有一个测试按钮可以用来发送测试设置是否正确。

同时在Test项目中的Building Settings打勾选中E-mail Notification,点击右边的问号，会出现帮助文档，说明在四种情况下会发送email，填写接受email的地址，然后故意将client代码修改到不能编译通过。然后点击Build now按钮测试一下。果然收到email.

8.检查代码更新并编译

可以通过Poll SCM来设置定时检查编译功能

比如*/5 * * * * 就是每隔5分钟检查一次，如果git仓库中有更新，则执行build操作。

 8. Jenkins → configuration下告诉jenkins你的JDK、GIT安装路径 

并配置GitHubWebHook连通你的git帐号

    9.  至此配置完毕， 现在开始建个自由风格的job， 各项的配置如下

                 当进行构建时， jenkins会去该url 获取你的代码到当前workspace

如果要实现email的发送，

需要安装iis， 配置smtp服务（不熟悉的同学网上搜一搜吧）

当然如果有现成的smtp服务，直接在jenkins -config页面填写，包括端口（默认22）

好啦，等不及的话先点击‘Build Now’ 手动构建吧，

验证jenkins如何自动构建：

   修改下本地git仓库的代码，commit 并push 到远程仓库， 等2分钟的样子，jenkins便会自动构建。（由于上面设置了每2分钟检查git源码仓库，如有checkin就触发构建）

在构建的控制台输出可查看构建的细节，如果顺利的话，如下

• A “Manage Credentials” screen on the “Manage Jenkins” screen allowing you to manage system and global credentials.
• If you are using Jenkins security, when you go to “Users” / your username / “Configure” you would see the option to manage personal credentials.
• Anywhere those credentials are needed, there is a drop down list of the appropriate available credentials, and you just select the appropriate one.
• When the time comes to change the password, you just change it once. 

And that is about it, from the end-user's perspective. A single point for managing each credential. Change it in one place and you are done.

As of version 1.5, the plugin now supports categorising credentials into different "domains" in order to allow plugins to restrict the choice of credentials to only those that are appropriate.

For example, you may use the same username with a different password on multiple services. e.g. Wile E Coyote may have an account with Acme Industries, Jenkins CI, etc. in each case using the same username but a different password.

If you need to select the credentials to use when connecting to a service, it can be difficult to ensure that you select the correct one. Selecting the wrong one may mean that the incorrect password triggers a service lockout.

Credential Domains are a solution to help with this problem.

When a plugin is asking for a list of credentials, it can add some specifications about where and how the credential will be used. If we configure the following Credential Domain: 
And we are trying to make an update to the Acme wiki (e.g. https://wiki.acme.com) then the plugin asking for credentials can say that it is looking for username/password credentials and it needs ones that support the https URI scheme, the hostname is wiki.acme.com and the port is 443. The credentials plugin will compare each credential domain's specification against the requirements and exclude any which do not match. Thus the user would be presented with the appropriate and relevant set of credentials.

When creating credential domains, it is important to note that domains are excluded based on requirements failing to match the specification. Thus if there is a specification for a specific URI scheme and the requirements do not detail a specific URI scheme then the credential domain is still considered to be a match. The logic is necessary to be this way in order to both allow existing plugins to retrieve credentials from within domains (even if they do not construct and supply a list of domain requirements) and also with the principle of allowing the user to be in control, i.e. the user can still select a credential if there is a possibility that the credential might apply, only where we know the credential is not appropriate do we exclude the domain.

Information for Plugin Developers

The credentials plugin provides two main extension points:

• Credentials - a base class for all Credentials types managed by the credentials plugin. Most plugin authors will just want to subclass this type to define what they need to store in the credential type... better yet, if you can find an existing Credentials subclass that stores your credentials.  So, for example, if somebody created a ssh-credentials plugin that just defines a SshCredentials class, then anyone needing ssh credentials could just depend on that... [Note that careful use of readResolve can allow this to be introduced after the fact]
• CredentialsProvider - an extension point for something that can provide credentials. For example, the CloudBees Folders plugin uses this extension point to provide folder scoped credentials, so that the credentials are only available to jobs within the folder.

When you need to get back some credentials you just callCredentialsProvider.lookupCredentials(type,item,auth,domainRequirements) to retrieve the appropriate credentials. 
The type parameter is the class of credentials you want to retrieve. 
The item parameter is the job you want to retrieve the credentials for, but this could also be the Jenkins instance itself; e.g., if getting the email credentials when Jenkins is sending emails, if getting the ssh credentials for Jenkins to start a slave node with, etc.
The auth parameter is the authentication that is requesting the credentials. In general this will be ACL.SYSTEM but, for example, the version 2.0 of the CloudBees Deployer plugin adds a “Deploy Now” action which allows a user to use their own user-scoped credentials to deploy an already built web application to their own RUN servlet container instance (useful for testing older builds to see if you have a valid test case for that bug).
The domainRequirements parameter is the list of requirements against which domain specifications will be verified when retrieving credentials.

Jenkins保留了一套内嵌命令行，允许你通过Shell脚本方式访问Jenkins并进行管理，这就极大的方便了一些日常自动化任务，包括故障诊断等等。

详细信息请参看官方Wiki：Jenkins-CLI

当然，如果你手头已经搭建了一台Jenkins服务器，那么你也可以访问你的Jenkins，然后通过Jenkins - Manage Jenkins - Jenkins CLI页面查看相关帮助，如下图：

Jenkins的命令行方式：

所有参数：

Jenkins保留了一套内嵌命令行，允许你通过Shell脚本方式访问Jenkins并进行管理，这就极大的方便了一些日常自动化任务，包括故障诊断等等。

详细信息请参看官方Wiki：Jenkins-CLI

当然，如果你手头已经搭建了一台Jenkins服务器，那么你也可以访问你的Jenkins，然后通过Jenkins - Manage Jenkins - Jenkins CLI页面查看相关帮助，如下图：

Jenkins的命令行方式：

所有参数：

要运行Jenkins的其它配置：

1，Jenkins是java程序，因此需要安装JDK。

2，同时运行job需要提供repository，也就是存放Jenkins定期poll源代码的地方。可以去github免费注册一个。

3，如果想在Jenkins中使用ant，maven等，则还需要单独安装。但不是必须的。

启动Jenkins

Jenkins天生支持unix-like system。

• 直接运行
  

好吧，Jenkins是一个java程序，所以要运行它，只需要：

$ java -jar jenkins.war

我们也可以使用nohup命令，让Jenkins在后台运行。

之后打开URL http://myServer:8080 就可以方便的操作Jenkins了

官网给了一个sh的例子，用于启动Jenkins。可以参考一下。

• 在Servlet container中运行

Alternatively, if you have a servlet container that supports Servlet 2.4/JSP 2.0, such as Glassfish v2, Tomcat 5 (or any later versions), then you can run them as services, and deployjenkins.war as you would any other war file.

For example,
you could simply place the jenkins.war file in Tomcat’s webapps directory.  此时使用的URL默认就变成：

http://localhost:8080/jenkins

同时Jenkins提供一些默认不会启动的特殊的功能，参考下面的link来enable它们。

https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties

Jenkins的目录结构

和CruiseControler一样，Jenkins需要一个目录来存储相关文件：JENKINS_HOME。默认为 ~/.jenkins。即为user的home目录下的一个隐藏目录。我们也可以更改JENKINS_HOME，指向我们希望的地方。

(注意因为是隐藏目录，所以需要使用ls -al 才能看到)

JENKINS_HOME
 +- config.xml     (jenkins root configuration)
 +- *.xml          (other site-wide configuration files)
 +- userContent    (files in this directory will be served under your http://server/userContent/)
 +- fingerprints   (stores fingerprint records)
 +- plugins        (stores plugins)
 +- jobs
     +- [JOBNAME]      (sub directory for each job)
         +- config.xml     (job configuration file)
         +- workspace      (working directory for the version control system)
         +- latest         (symbolic link to the last successful build)
         +- builds
             +- [BUILD_ID]     (for each build)
                 +- build.xml      (build result summary)
                 +- log            (log file)
                 +- changelog.xml  (change log)

如果有权限管理，则在HOME目录下还会有users目录。

从目录结构来看，和CruiseController非常相似。其中config.xml是Jenkins重要的配置文件。我们都知道Jenkins用于monitor多个build，而jobs这个目录无疑就是存储每个build相关信息的地方。

总的来说，Jenkins目录结构非常直白，简洁。

备份和恢复

备份和恢复非常简单，就是简单的copy Jenkins的目录就好了：

All the settings, build logs, artifact archives are stored under the JENKINS_HOME directory. Simply archive this directory to make a back up. Similarly, restoring the data is just replacing the contents of the JENKINS_HOME directory from a back up.

移动/拷贝/重命名 job

由于每个jobs都有自己单独的目录，我们可以很容易的：

    1，move a job from one installation of Jenkins to another by simply copying the corresponding job directory.
   ,2，make a copy of an existing job by making a clone of a job directory by a different name.
    3，rename an existing job by renaming a directory.

修改后执行下面的命令刷新：

http://[jenkins-server]/[command] 

在这里[command]可以是：exit 退出，restart 重启， reload 重载。

创建一个Project

因为Jenkins可以用于运行各种CI，测试，批处理任务等等，所以在Jenkins中将这些任务统称为“free-style software project”.

Jenkins也提供了其他类型的jobs，例如：

1，如果项目是Maven，Jenkins还提供了一种仅用于Maven Project的job。但其实free-style software projec仍然可以用于创建Maven项目，只不过这种更适合Maven项目，结合的更好而已。

2，也可以创建一个"Monitor an external job“用于监控外部进程。

3，或者一个Matrix project，也就是multi-configuration project。

我不确定是否仅有这4种job，也许使用插件可以创建更多类型的job，大家自己看资料吧。

下面是如何创建一个最常见的“free-style software project"的过程：

ok确定

这之前有很多描述性的工作可以自己选择，配置svn要Subersion，在Repository URL中输入svn地址，点击enter credential

这里输入svn用户名和密码即可，在已建项目中可以点击Configure

自动运行Build

触发一个build有三种方式：

• Builds in Jenkins can be triggered periodically (on a schedule, specified in configuration) 这里定义schedule的语法是unix常见的cron语法。
  
• Or when source changes in the project have been detected

可以设置Jenkins定时检查SVN是否发生了变化，也可以手动检查：http://YOURHOST/jenkins/job/PROJECTNAME/pollong。也可以设置Jenkins为post-commit，这个方式尤其适用于那些检查是否代码改变会花费很长时间的情况。

• Or they can be automatically triggered by requesting the URL:

http://YOURHOST/jenkins/job/PROJECTNAME/build

Distributed builds

Jenkins supports the "master/slave" mode, where the workload of building projects are delegated to multiple "slave" nodes, allowing single Jenkins installation to host a large number of projects, or provide different environments needed for builds/tests.

在现实中需要使用distributed builds情况很多，例如：一个web application的build，需要分别验证firefox和IE的行为，那么就需要到windows机器上运行IE。

或因为性能问题，将build分布到多个slave节点去。

到Jenkins的管理界面，就可以方便的添加节点。配置节点时，需要提供节点所在的机器，登陆用户名密码，使用的目录等。

但是slave并不需要再安装Jenkins。jenkins会自动启用slave agent，将build需要tools考到远程机器上。

需要注意的是：the build results and artifacts will always end up on the master server. 因此不需要跑到各个节点去查看build产生的文件，log等。

其实在slave节点，会创建一个本地的workspace，并在运行时使用这个workspace。因为毕竟build运行在slave节点上，所以这个节点肯定要有运行build需要的所有因素。

总之添加节点并远程运行build真是太方便了~

添加节点后，在master Jenkins home目录下会出现关于该节点的配置文件。

Jenkins将自动决定在哪个节点上运行build，根据下列策略：

Some slaves are faster, while others are slow. Some slaves are closer (network wise) to a master, others are far away. So doing a good build distribution is a challenge. Currently, Jenkins employs the following strategy:

1. If a project is configured to stick to one computer, that's always honored.
2. Jenkins tries to build a project on the same computer that it was previously built.
3. Jenkins tries to move long builds to slaves, because the amount of network interaction between a master and a slave tends to be logarithmic to the duration of a build (IOW, even if project A takes twice as long to build as project B, it won't require double network transfer.) So this strategy reduces the network overhead.

Jenkins通过运行slave agents来完成分布式build。最常见的情况是：slave agent运行在各个slave 节点。master通过SSH远程启动/停止slave agent，进而控制各个节点的行为。

一共有下列4种方式启动slave agent：

•The master starts the slave agents via ssh
• Starting the slave agent manually using Java Web Start
• Installing the slave agent as a Window service
• Starting the slave agent directly from the command line on the slave machine from the command line

需要注意的是这4种方式适用于不同的情况，例如slave节点在防火墙后，导致master无法通过SSH启停slave agent。此时只能用后三种方式，但是往往有一些弊端，比如master无法自动停止/重启 slave agent.

一旦添加node成功，你就可以在job中指定这个job在哪个node运行：

Restrict where this project can be run (如果不指定则由Jenkins自行决定，即可以在slave节点运行，也可以在master节点运行，甚至在一次build中就可以自行来回切换)。

配置Jenkins，让它收集更多的log

https://wiki.jenkins-ci.org/display/JENKINS/Logging

在流行持续集成的今天，在各个环境：alpha,beta和production 都部署了唯一的Jenkins服务器。

Jenkins服务器统一负责该环境内所有组件的持续集成。也就是说，一个Jenkins服务器会有很多个build。所以有时会用到上面提到的”Monitor an external job“。

但不是Distributed Builds。

同时由于Jenkins会进入每个环境，包括production，因此会使用auto deployment的方式，自动完成Jenkins在各个环境的部署。

用户管理

毫无疑问Jenkins中需要有用户管理的功能，因为除开发人员外，有多种角色的人需要查看build的结果。

在Jenkins中的系统管理中，可以设置“任何用户可以做任何事” 或 “登录用户可以做任何事”。

因此前一个选项意味着，任何浏览JenkinsURL的用户都可以修改Jenkins。或只有登录用户才能做修改。

Jenkins中的用户划分为两类：可登录用户和不可登录用户。

1，只要是修改过repository，即对build产生过影响的用户，都会被Jenkins记录在本地的database中。这类用户可以在Jenkins界面->查看用户中浏览。

但这类用户不是正式的Jenkins用户，也不能登录Jenkins。这类用户的权限由上面说的系统管理中的配置决定。通常只有查看build的权限，没有修改权限。

2，只有在Jenkins中明确注册的用户，才能够登录Jenkins，并且有权限控制。同时注册过的用户，在JENKINS_HOME目录下的users目录下，都有一个单独的目录来存储相关信息。

Jenkins Script Console

Jenkins提供了一个script console Groovy script which allows to run arbitrary scripts on the Jenkins server or on slave nodes. This feature can be accessed from the "manage Jenkins" link。

也可以通过URL直接访问：http://myserver:8080/hudson/script

Hudson的特性

2定义编辑

3价值编辑

减少风险

减少重复过程

任何时间、任何地点生成可部署的软件

增强项目的可见性

建立团队对开发产品的信心

4要素编辑

5原则编辑