广东seo推广费用,seo站长综合查询工具,企业网站备案费用,wordpress附件修复/*************************/
拥抱变化 是敏捷的态度之一, CruiseControl 正是来实证这种态度的作品. 多种类型的变化都会触发CruiseControl的一次构建过程.
我们知道CruiseControl能根据源代码的变化来调度一次构建, 但你知道CruiseControl支持多少… /*************************/
拥抱变化 是敏捷的态度之一, 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 time0300 ... / 每天的某个时间段之外的时间来构建, 参见pause插件, 如每天的凌晨2点至6点不要构建:
schedule ant .../ pause starttime0200 endtime0600/ /schedule 每天的某个时间段之内的时间来构建, 参见pause插件, 如每天的凌晨2点至6点之间构建:
schedule ant .../ pause starttime0000 endtime0200/ pause starttime0600 endtime2359/ /schedule 从这里我们可以看出CruiseControl缺少对 not 的支持
2.2 一周之内的调度 一周内的每天都调度, 这是ant, pause等的缺省行为 每周的某一天来构建或不构建, 参见ant, pause等的day属性. 如每周三构建, ant dayWednesday ... /, 可以和time属性结合使用, 如每周四的23点等
这样就有总共 3*26 种基于时间的调度 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 interval60 ant targetmasterbuild / ant targetcleanbuild multiple5//schedule Fallback Build, 用固定时间的构建来弥补一整天没有源代码变化的非敏捷情形, 参见timebuild插件 modificationset cvs localworkingcopy/home/project timebuild usernameyou_guys_are_not_agile time2300//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/CruiseControlSchedulingScenarios CruiseControl Enterprise 最佳实践 (1) : Publish with a Publisher CruiseControl Enterprise 最佳实践 (2) : Keep your dependencies to yourself CruiseControl Enterprise 最佳实践 (3) : Configuring CruiseControl the CruiseControl way
