Jenkins(二) 安装、新建Jobs与删除及SVN配置（转）

官网首页（https://jenkins-ci.org/）就提供了windows版本的Jenkins安装包。能够本身下载一个用于学习。安装后自动打开http://localhost:8080，就能够看见Jenkins的界面。
http://mirrors.jenkins-ci.org/

要运行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

http://blog.csdn.net/tiangwan2011/article/details/7597080