CruiseControl Enterprise 最佳实践 (1) : Publish with a Publisher

CruiseControl Enterprise 最佳实践 (1) : Publish with a Publisher

©Copyright 2007 Julian Simpson. All rights reserved.

英文原文: CruiseControl Enterprise: 10 Best Practices

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时开发者可以继续工作了, 提高了并发性, 还是省时间