Jenkins

jenkins是一個開源軟體項目，旨在提供一個開放易用的軟體平台，使持續內建變成可能。[1]

jenkins，之前叫做hudson，是基于java開發的一種持續內建工具，用于監控秩序重複的工作，包括：

1、持續的軟體版本釋出/測試項目。

2、監控外部調用執行的工作。

jenkins搭建

下載下傳jenkins.war

有兩種啟動方法。

首先保證系統中已經安裝了jdk，最好是jdk1.5以上。

第一種啟動方法，切換到jenkins.war存放的目錄，輸入如下指令：

$ java -jar jenkins.war

然後在浏覽器中（推薦用火狐）輸入http://localhost:8080，localhost可以是本機的ip，也可以是計算機名。就可以打開jenkins

第二種方法是用tomcat打開

解壓tomcat到某個目錄,如/usr/local，進入tomcat下的/bin目錄，啟動tomcat

将jenkins.war檔案放入tomcat下的webapps目錄下，啟動jenkins時，會自動在webapps目錄下建立jenkins目錄，是以在位址欄上需要輸入的位址于上一種方法有點不一樣：

http://localhost:8080/jenkins。

從代碼倉庫擷取代碼用svn，做單元測試用junit，做代碼檢查用pmd、findbugs，代碼編譯、打包用ant，拷貝檔案到部署伺服器上用shell，出現bug了通知開發人員要發email，工具一多了，整合起來用時，不斷切換界面，輸入指令的複雜性可想而知，有沒有一站式的工具可以代勞呢？

有，這就是jenkins，有了她，你就可以：通過統一的web界面做各種配置工作、檢視工具的log輸出、即使是曆史的日志檢視也沒問題；通知配置排程，可以自動的擷取代碼、編譯、打包和部署，發郵件，無須人工幹預。

安裝jenkins，其實就是把一個war包放到容器中

安裝插件：發郵件插件jenkins email extension plugin和部署插件deploy to container plugin

配置jdk和郵件伺服器位址

建立任務：配置svn位址/配置建構排程@hourly/配置建構步驟，如先用ant編譯打包再傳到伺服器/配置成功或失敗後發郵件通知的位址

手動執行任務或等待時間到了後執行任務

各種插件的安裝ant：如果在jenkins中使用了ant-junit，由于jenkins是直接調用作業系統的ant指令的，是以要在linux下安裝ant，配置ant_home，并将bin加入到path中：

ant_home=/opt/ant/apache-ant-1.8.2

java_home=/usr/java/jdk1.6.0_29

jre_home=/usr/java/jdk1.6.0_29/jre

path=$ant_home/bin:$java_home/bin:jre_home/bin:$path

classpath=.:$java_home/lib/jt.jar:$java_home/lib/tools.jar:$jre_home/lib

export ant_home java_home jre_home path classpath

官網：https://wiki.jenkins-ci.org/display/jenkins/meet+jenkins

我的這篇文章僅僅是簡單的根據上文，介紹jenkins提供了哪些功能。具體大家還是要自己學習啦~

官網首頁就提供了windows版本的jenkins安裝包。我們可以下載下傳一個用于學習。安裝後自動打開http://localhost:8080，你就能看見jenkins的界面了。

其他也需要安裝的是：

1，jenkins是java程式，是以需要安裝jdk。

2，同時運作job需要提供repository，也就是存放jenkins定期poll源代碼的地方。我們可以去github免費注冊一個。

3，如果想在jenkins中使用ant，maven等，則還需要單獨安裝。但不是必須的。

啟動jenkins

jenkins天生支援unix-like system。

直接運作

好吧，jenkins是一個java程式，是以要運作它，隻需要：

我們也可以使用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"的過程：

go to jenkins top page, select "new job", then choose "build a free-style software project". this job type consists of the following elements:

optional scm, such as cvs or subversion where your source code resides. 指定源代碼在哪。

note: in software engineering, software configuration management (scm) is the task of tracking and controlling changes in the software.

optional triggers to control when jenkins will perform builds. 指定jenkins何時觸發一次build。

some sort of build script that performs the build (ant, maven, shell script, batch file, etc.) where the real work happens 觸發build時，使用的腳本檔案，例如ant。在這個腳本檔案中，我們可以從svn下載下傳最新代碼，删除上次build的臨時檔案，建立必要目錄，編譯源代碼，運作，打包等一系列工作。

optional steps to collect information out of the build, such as archiving the artifacts and/or recording javadoc and test results. 收集log資訊。

optional steps to notify other people/systems with the build result, such as sending e-mails, ims, updating issue tracker, etc. 通知相關人員build的結果。

例如我們使用的build script就是ant，在jenkins中運作ant。在腳本檔案中，可以直接使用jenkins提供的一些變量。

同時，每個job可以有多個step。例如：将運作程式定義為step1，運作單元測試定義為step2，生成coverage報告定義為step3。

同時還可以定義post-build action。例如：生成javadoc，或清理程式運作的臨時檔案目錄等。

自動運作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:

if a project is configured to stick to one computer, that's always honored.

jenkins tries to build a project on the same computer that it was previously built.

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

我想這對于初學jenkins的人，用來判斷問題所在太有用了。

在流行持續內建的今天，我們在各個環境：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目錄下，都有一個單獨的目錄來存儲相關資訊。我不太清楚是否能夠通過copy/paste将使用者部署到其他地方去，回頭測試一下。

既然要滿足各種人對jenkins使用的各種需求，是以權限管理遠沒有這麼簡單。具體大家還得自己去看啊~

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

可惜隻能用groovy 反證我不懂。