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

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

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

 

没有更多推荐了,返回首页