切尔斯基

/*************************/

"拥抱变化" 是敏捷的态度之一, 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>等的缺省行为

• 每周的某一天来构建或不构建, 参见<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