標籤:des style http color java 使用 os io
官網: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程式,所以要執行它,僅僅須要:
$ java -jar jenkins.war
我們也能夠使用nohup命令,讓Jenkins在後台執行。
之後開啟URL http://myServer:8080 就能夠方便的操作Jenkins了
官網給了一個sh的範例,用於啟動Jenkins。能夠參考一下。
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檔案夾結構很直白,簡潔。
備份和恢複
備份和恢複很easy,就是簡單的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都有自己單獨的檔案夾,我們能夠非常easy的:
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的管理介面,就能夠方便的加入?節點。配置節點時,須要提供節點所在的機器,登陸usernamepassword,使用的檔案夾等。
可是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 都部署了唯一的Jenkinsserver。
Jenkinsserver統一負責該環境內全部組件的持續整合。也就是說,一個Jenkinsserver會有非常多個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 反證我不懂。