CruiseControl 的 108 种调度模式

 

 

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

"拥抱变化" 是敏捷的态度之一, CruiseControl 正是来实证这种态度的作品. 多种类型的"变化"都会触发CruiseControl的一次构建过程.

我们知道CruiseControl能根据源代码的变化来调度一次构建, 但你知道CruiseControl支持多少种调度模式吗?

---切尔斯基

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

 

1. 基于 "源代码变化" 的调度 ( 3 种)

这是 CruiseControl 最经典的调度模式, 可以参见

• 一个小扩展, 基于 "部分源代码变化" 的调度, 参见的 "ignoreFiles" 属性

• 一个小扩展, "不需要任何源代码变化" 的调度, 参见的 "requiremodification" 属性(Deprecated), 和的"requireModification"属性(Recommended)

 

2. 基于 "时间变化" 的调度 ( 6 种)

这是另外一种常用的调度模式, 通常用于 Nightly Build. 但是 CruiseControl 并没有从架构级别上支持这种调度, 基于时间的调度被分散到各个插件中, 得自己去看文档寻找

以常用的几种插件为例, 我们来看看CruiseControl支持的几种基于 "时间变化" 的调度模式

2.1 一天之内的调度

• 每天的某个时刻来构建, 参见的"time"属性. 如每天的凌晨3点构建, ""

• 每天的某个时间段之外的时间来构建, 参见插件, 如每天的凌晨2点至6点不要构建:

   

   

• 每天的某个时间段之内的时间来构建, 参见插件, 如每天的凌晨2点至6点之间构建:

   

   

   

从这里我们可以看出CruiseControl缺少对 的支持

2.2 一周之内的调度

• 一周内的每天都调度, 这是, 等的缺省行为

• 每周的某一天来构建或不构建, 参见, 等的"day"属性. 如每周三构建, "", 可以和"time"属性结合使用, 如每周四的23点等

这样就有总共 3*2=6 种基于时间的调度

 

3. 基于 "依赖变化" 的调度 ( 6 种)

通常我们会将大的项目分成多个小项目来组织构建, 这些小项目之间有依赖关系, 某个项目要等待另外一个成功之后再构建才有意义, 比如说要用到其它project的构建产物来作为输入, 我们将这种情况称之为Build Pipeline

CruiseControl并没有对项目之间的依赖, 或曰Build Pipeline提供显式建模或支持, 只是有一些插件来局部支持

• 你依赖的某个project构建成功后再构建, 参见插件

• 你依赖的某个project构建成功, 并且当你自己的project试图构建时, 你依赖的project还是最新的(源代码没有变化)时再构建, 参见插件

• 当硬盘上某个文件变化后再构建, 通常这个文件是其它project的构建产物, 参见插件

• 当Web服务器上的某个文件变化后再构建, 参见插件

• 基于上次构建结果的调度, 参见的"buildafterfailed"属性

• 多线程模式下某几个项目不能同时构建, 参见, 插件

 

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

由于 可以包含多个插件, 并且缺省是 OR 的关系, 所以你基本上可以正交的应用前面提到的所有调度模式, 这样你就能得到 3 * 6 * 6 = 108 种调度模式

下面描述两种令上述模式都失效的调度模式

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

 

4. 基于 "强制命令" 的调度

• 固定时间间隔的构建, 不管有没有源代码变化, 一种方式是前面提到的的"requireModification"属性, 另一种请参见插件

• 按需构建, 只有你通过UI或JMX显式的来触发构建的时候才构建, 一种方式是的"forceOnly"属性, 另一种请参见插件

 

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

在使用CruiseControl的过程中, 通常会遇到某些构建比较耗时, 或者检查整个源代码仓库的时间过长等情况. 对此 CruiseControl 提供了一些优化措施

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

 

5. 优化调度

• 每运行另外的构建一定次数, 才运行一次本构建, 通常用于调度耗时较长的如 Clean Build 等, 参见的"multiple"属性.

   
    multiple="5"/>

• Fallback Build, 用固定时间的构建来弥补一整天没有源代码变化的非敏捷情形, 参见插件

   
   

• 先进行耗时耗资源少的检查, 有变化后再全面检查取得所有变化, 参见插件

• 同时运行多个构建, 参见插件

 

缺少的那一块

• CruiseControl用来抽象"变化"这一概念, 但是官方提供的插件侧重于"源代码变化", 却相对忽略了对"时间变化"的支持, 应该有插件来支持所有基于时间变化调度的模式, 而不是由等Builder来做

• CruiseControl缺乏对project之间依赖关系, 或Build Pipeline的支持

• CruiseControl的插件容器基本上是 OR 的关系, 缺乏对逻辑关系的显式建模, 应该提供 AND, NOT 等关系, 这样我们就能组合应用已有的插件. CruiseControl的现状是分别提供了, , 等插件

• CruiseControl已经提供了来抽象"变化"这一概念, 却又提供了的几个属性"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