/*************************/
"拥抱变化" 是敏捷的态度之一, 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
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/axzywan/archive/2008/11/28/3399861.aspx
分享到:
相关推荐
更多地,它是一种研发模式的转变。CruiseControl是一著名的CI服务器。本次交流会从零介绍它的使用,并附带大量的Demo演示。 注意,持续集成本身也是一持续改进的过程。如何逐渐提升可回归性、敏捷性,这是一个永恒...
cruisecontrol配置定时运行
CruiseControl简介及使用举例
CruiseControl.NET 是 .NET 平台下的持续集成工具,CruiseControl (Java) 的 .NET 移植版本。CruiseControl是一个针对持续构建程序(项目持续集成)的框架,它包括一个email通知的插件,Ant和各种各样的CVS工具。Cruise...
cruisecontrol配置文件,很实用
CruiseControl-2.8.4.exe
cruisecontrol简介
cruisecontrol+maven2配置做持续集成
[CruiseControl]binary安装和启动
cruisecontrol、ant、svn持续集成 己两个多星期以来对持续集成的概念和应用有了一些了解。下面主要对自己配置持续集成的环境进行总结。(看上去简单,但是对我开始对持续集成都没什么了解的人来说确实费了不少周折)
CruiseControl.NET-CCTray-1.8.4.0-Setup.exe
CruiseControl.NET-1.4.4-Setup.exe
CruiseControl笔记,详细介绍了CruiseControl。net的配置,希望对大家有所帮助
With the emergence of vehicle-to-vehicle communi-cation technology, cooperative adaptive cruise control (CACC) cars can be expected in the near future. In this paper, novel criteria for string ...
CruiseControl.NET-CCTray-1.5.6804.1-Setup
而现在,CruiseControl已发展成为一个家族式系统,包括CruiseControl.java、CruiseControl.net、CruiseControl.ruby等适应不同语言环境的实现,其强大的插件和扩展能力也是诸多同类系统无法比你的。而在这里,我只...
剖析CruiseControl:在没有应用持续集成之前,传统的开发模式是项目一开始就划分模块,然后等所有的代码都开发完成之后再集成到一起进行测试,软件规模也在扩大,软件需求越来越复杂,软件已经不能简单地通过划分...
1.认识CruiseControl 2.CruiseControl的安装 3. CruiseControl的配置 4.总结
CruiseControl.NET-1.8.2.0-Setup.exe ccnet 服务端