/*************************/
"擁抱變化" 是敏捷的態度之一, CruiseControl 正是來實證這種態度的作品. 多種類型的"變化"都會觸發CruiseControl的一次構建過程.
我們知道CruiseControl能根據源代碼的變化來調度一次構建, 但你知道CruiseControl支持多少種調度模式嗎?
---切爾斯基
/*************************/
1. 基於 "源代碼變化" 的調度 ( 3 種)
這是 CruiseControl 最經典的調度模式, 可以參見 <modificationset>
-
一個小擴展, 基於 "部分源代碼變化" 的調度, 參見<modificationset>的 "ignoreFiles" 屬性
-
一個小擴展, "不需要任何源代碼變化" 的調度, 參見<modificationset>的 "requiremodification" 屬性(Deprecated), 和<project>的"requireModification"屬性(Recommended)
2. 基於 "時間變化" 的調度 ( 6 種)
這是另外一種常用的調度模式, 通常用於 Nightly Build. 但是 CruiseControl 並沒有從架構級別上支持這種調度, 基於時間的調度被分散到各個插件中, 得自己去看文檔尋找
以常用的幾種插件爲例, 我們來看看CruiseControl支持的幾種基於 "時間變化" 的調度模式
2.1 一天之內的調度
-
每天的某個時刻來構建, 參見<ant>的"time"屬性. 如每天的凌晨3點構建, "<ant time='0300' ... />"
-
每天的某個時間段之外的時間來構建, 參見<pause>插件, 如每天的凌晨2點至6點不要構建:
<schedule><ant .../>
<pause starttime="0200" endtime="0600"/>
</schedule>
-
每天的某個時間段之內的時間來構建, 參見<pause>插件, 如每天的凌晨2點至6點之間構建:
<schedule><ant .../>
<pause starttime="0000" endtime="0200"/>
<pause starttime="0600" endtime="2359"/>
</schedule>
從這裏我們可以看出CruiseControl缺少對 <not> 的支持
2.2 一週之內的調度
-
每週的某一天來構建或不構建, 參見<ant>, <pause>等的"day"屬性. 如每週三構建, "<ant day='Wednesday' ... />", 可以和"time"屬性結合使用, 如每週四的23點等
這樣就有總共 3*2=6 種基於時間的調度
3. 基於 "依賴變化" 的調度 ( 6 種)
通常我們會將大的項目分成多個小項目來組織構建, 這些小項目之間有依賴關係, 某個項目要等待另外一個成功之後再構建纔有意義, 比如說要用到其它project的構建產物來作爲輸入, 我們將這種情況稱之爲Build Pipeline
CruiseControl並沒有對項目之間的依賴, 或曰Build Pipeline提供顯式建模或支持, 只是有一些插件來局部支持
-
你依賴的某個project構建成功後再構建, 參見<buildstatus>插件
-
你依賴的某個project構建成功, 並且當你自己的project試圖構建時, 你依賴的project還是最新的(源代碼沒有變化)時再構建, 參見<veto>插件
-
當硬盤上某個文件變化後再構建, 通常這個文件是其它project的構建產物, 參見<filesystem>插件
-
當Web服務器上的某個文件變化後再構建, 參見<httpfile>插件
-
基於上次構建結果的調度, 參見<project>的"buildafterfailed"屬性
-
多線程模式下某幾個項目不能同時構建, 參見<lockfilelistener>, <lockfilebootstrapper>插件
/*************************/
由於 <modificationset> 可以包含多個插件, 並且缺省是 OR 的關係, 所以你基本上可以正交的應用前面提到的所有調度模式, 這樣你就能得到 3 * 6 * 6 = 108 種調度模式
下面描述兩種令上述模式都失效的調度模式
/*************************/
4. 基於 "強制命令" 的調度
-
固定時間間隔的構建, 不管有沒有源代碼變化, 一種方式是前面提到的<project>的"requireModification"屬性, 另一種請參見<alwaysbuild>插件
-
按需構建, 只有你通過UI或JMX顯式的來觸發構建的時候才構建, 一種方式是<project>的"forceOnly"屬性, 另一種請參見<forceonly>插件
/*************************/
在使用CruiseControl的過程中, 通常會遇到某些構建比較耗時, 或者檢查整個源代碼倉庫的時間過長等情況. 對此 CruiseControl 提供了一些優化措施
/*************************/
5. 優化調度
-
每運行另外的構建一定次數, 才運行一次本構建, 通常用於調度耗時較長的如 Clean Build 等, 參見<ant>的"multiple"屬性.
<schedule interval="60">
<ant target="masterbuild" />
<ant target="cleanbuild" multiple="5"/>
</schedule>
-
Fallback Build, 用固定時間的構建來彌補一整天沒有源代碼變化的非敏捷情形, 參見<timebuild>插件
<modificationset>
<cvs localworkingcopy="/home/project">
<timebuild username="you_guys_are_not_agile" time="2300"/>
</modificationset>
-
先進行耗時耗資源少的檢查, 有變化後再全面檢查取得所有變化, 參見<compound>插件
-
同時運行多個構建, 參見<threads>插件
缺少的那一塊
-
CruiseControl用<modificationset>來抽象"變化"這一概念, 但是官方提供的插件側重於"源代碼變化", 卻相對忽略了對"時間變化"的支持, 應該有插件來支持所有基於時間變化調度的模式, 而不是由<ant>等Builder來做
-
CruiseControl缺乏對project之間依賴關係, 或Build Pipeline的支持
-
CruiseControl的插件容器基本上是 OR 的關係, 缺乏對邏輯關係的顯式建模, 應該提供 AND, NOT 等關係, 這樣我們就能組合應用已有的插件. CruiseControl的現狀是分別提供了<compound>, <composite>, <compoundpublisher>等插件
-
CruiseControl已經提供了<modificationset>來抽象"變化"這一概念, 卻又提供了<project>的幾個屬性"requireModification", "forceOnly", "buildafterfailed"來控制調度, 實屬畫蛇添足.
參考
-
CruiseControl Scheduling Scenarios: http://confluence.public.thoughtworks.org/display/CC/CruiseControl+Scheduling+Scenarios
-
CruiseControl Enterprise 最佳實踐 (1) : Publish with a Publisher
-
CruiseControl Enterprise 最佳實踐 (2) : Keep your dependencies to yourself
-
CruiseControl Enterprise 最佳實踐 (3) : Configuring CruiseControl the CruiseControl way