I'm an Infrastructure Specialist at
ThoughtWorks. In my role I
make sure that we are building our software so it can successfully be
deployed to production. In this series of blog posts I hope
to
pass on my top ten tips for using CruiseControl Enterprise
effectively. I'm writing these with the developers or systems
administrators in mind: the people who most often manage
CruiseControl. However, I hope that anybody who is interested
in
Continuous Integration will get something from these articles.
# 1: Publish with a Publisher : 使用 Publisher 來發布, 而不是在構建過程中發布
許多項目都會用到"發布"的概念: 把構建產物放到指定地方, 或者把測試結果發送給最終用戶.
ArtifactsPublisher 就是一種很常用的方式,
用來把文件發布到CruiseControl自己的時間戳目錄形式的倉庫中, 這樣構建日志,
構建產物和測試結果等就可以通過新的CruiseControl Dashboard或者傳統的CruiseControl
Reporting應用展現出來.
ArtifactsPublisher不過是整個 Publisher 家族中的一員, 而我的最愛是
AntPubliisher. 如果你的Ant構建以發布構建產物到倉庫中或者給你的版本控制系統打Tag來結束,
那么或許應該用另外的方式來做這些事情. 考慮下面的CruiseControl調用的Ant腳本例子:
<project>
<target name="dist" description="build everything">
</target>
<target name="clean" description="delete all build artifacts">
</target>
<target name="test" description="run unit tests">
</target>
<target name="publish" description="publish to repository">
</target>
<target name="cruise" depends="clean,dist,test,publish"/>
</project>
構建的最后一步是通過 "publish" target 發布通過了單元測試的工作產物到某個倉庫或類似的地方.
這對于CruiseControl來說不錯, 很好, 但是, "發布"的概念并不真正適合在開發者的構建過程中使用.
如果我們能夠斷開"發布"和構建過程的其它部分之間的聯系, 開發者就能夠和CruiseControl使用一模
一樣的構建過程. 要想這樣做, 只需要讓CruiseControl來調用你開發過程中使用的構建腳本,
而把"publish"作為一個獨立的Ant target:
<project>
<target name="dist" description="build everything">
</target>
<target name="clean" description="delete all build artifacts">
</target>
<target name="test" description="run unit tests">
</target>
<target name="dev" depends="clean,dist,test"/>
<target name="publish"
description="publish to repository"
if="logfile">
</target>
</project>
'publish' target 中的 'if' 屬性用來保證這個target只會被 publisher 或某個特定的人來運行. 接下來,
只需改動一下CruiseControl的配置:
<!-- some config removed from
this example -->
<schedule interval="60">
<ant antWorkingDir="${checkout.dir}"
buildfile="build.xml"
target="dev"/>
</schedule>
<publishers>
<onsuccess>
<antpublisher antWorkingDir="${checkout.dir}"
buildfile="build.xml"
target="publish"/>
<onsuccess>
</publishers>
OK, 這就做完了. 一旦你應用了新的配置, CruiseControl就會運行和開發者一模一樣的Ant構建.
這意味著構建失敗時并不是因為 "CruiseControl" 做了什么神秘的事.
這還有助于通過更快的報告成功或失敗來縮短構建的反饋周期. 當開發者在慶祝或郁悶于構建的成功或失敗時,
AntPublisher 在同一時間繼續做著把構建產物發布到網絡上的工作. 我還用它來為codebase打tag,
如果構建成功的話--這件事也是"持續集成"的一部分.
Publishers 能夠被直接用在配置文件的<publishers>元素中,
這樣每次構建結束后無論成功失敗都會運行.
也可以包在<onsuccess>或<onfailure>中有條件的運行.
Publishers 有一個堂兄妹表姐弟叫 Bootstrappers, 我另外找時間說說它.
-----------------------------
我想這個實踐的好處就是
1. 開發者每次在自己機器上構建時不需要發布, 省時間
2. CruiseControl使用跟開發者相同的構建腳本, 減少了開發者構建成功而CruiseControl構建失敗的概率, 省調試時間
3. CruiseControl運行Publisher時開發者可以繼續工作了, 提高了并發性, 還是省時間