I'm an Infrastructure Specialist at
ThoughtWorks. In my role I
make sure that we are building our software so it can successfully be
deployed to production. In this series of blog posts I hope
to
pass on my top ten tips for using CruiseControl Enterprise
effectively. I'm writing these with the developers or systems
administrators in mind: the people who most often manage
CruiseControl. However, I hope that anybody who is interested
in
Continuous Integration will get something from these articles.
# 1: Publish with a Publisher : 使用 Publisher 来发布, 而不是在构建过程中发布
许多项目都会用到"发布"的概念: 把构建产物放到指定地方, 或者把测试结果发送给最终用户.
ArtifactsPublisher 就是一种很常用的方式,
用来把文件发布到CruiseControl自己的时间戳目录形式的仓库中, 这样构建日志,
构建产物和测试结果等就可以通过新的CruiseControl Dashboard或者传统的CruiseControl
Reporting应用展现出来.
ArtifactsPublisher不过是整个 Publisher 家族中的一员, 而我的最爱是
AntPubliisher. 如果你的Ant构建以发布构建产物到仓库中或者给你的版本控制系统打Tag来结束,
那么或许应该用另外的方式来做这些事情. 考虑下面的CruiseControl调用的Ant脚本例子:
<project>
<target name="dist" description="build everything">
</target>
<target name="clean" description="delete all build artifacts">
</target>
<target name="test" description="run unit tests">
</target>
<target name="publish" description="publish to repository">
</target>
<target name="cruise" depends="clean,dist,test,publish"/>
</project>
构建的最后一步是通过 "publish" target 发布通过了单元测试的工作产物到某个仓库或类似的地方.
这对于CruiseControl来说不错, 很好, 但是, "发布"的概念并不真正适合在开发者的构建过程中使用.
如果我们能够断开"发布"和构建过程的其它部分之间的联系, 开发者就能够和CruiseControl使用一模
一样的构建过程. 要想这样做, 只需要让CruiseControl来调用你开发过程中使用的构建脚本,
而把"publish"作为一个独立的Ant target:
<project>
<target name="dist" description="build everything">
</target>
<target name="clean" description="delete all build artifacts">
</target>
<target name="test" description="run unit tests">
</target>
<target name="dev" depends="clean,dist,test"/>
<target name="publish"
description="publish to repository"
if="logfile">
</target>
</project>
'publish' target 中的 'if' 属性用来保证这个target只会被 publisher 或某个特定的人来运行. 接下来,
只需改动一下CruiseControl的配置:
<!-- some config removed from
this example -->
<schedule interval="60">
<ant antWorkingDir="${checkout.dir}"
buildfile="build.xml"
target="dev"/>
</schedule>
<publishers>
<onsuccess>
<antpublisher antWorkingDir="${checkout.dir}"
buildfile="build.xml"
target="publish"/>
<onsuccess>
</publishers>
OK, 这就做完了. 一旦你应用了新的配置, CruiseControl就会运行和开发者一模一样的Ant构建.
这意味着构建失败时并不是因为 "CruiseControl" 做了什么神秘的事.
这还有助于通过更快的报告成功或失败来缩短构建的反馈周期. 当开发者在庆祝或郁闷于构建的成功或失败时,
AntPublisher 在同一时间继续做着把构建产物发布到网络上的工作. 我还用它来为codebase打tag,
如果构建成功的话--这件事也是"持续集成"的一部分.
Publishers 能够被直接用在配置文件的<publishers>元素中,
这样每次构建结束后无论成功失败都会运行.
也可以包在<onsuccess>或<onfailure>中有条件的运行.
Publishers 有一个堂兄妹表姐弟叫 Bootstrappers, 我另外找时间说说它.
-----------------------------
我想这个实践的好处就是
1. 开发者每次在自己机器上构建时不需要发布, 省时间
2. CruiseControl使用跟开发者相同的构建脚本, 减少了开发者构建成功而CruiseControl构建失败的概率, 省调试时间
3. CruiseControl运行Publisher时开发者可以继续工作了, 提高了并发性, 还是省时间