使用Hudson和FindBugs进行持续集成和代码检查

最近在IBM developerWorks发表的一篇文章中谈到了如何使用开源工具将构建过程中的持续集成（Continuous Integration，CI）和代码检查这两项任务自动化。它描述了如何安装和配置Hudson——一款由java.net社区开发的CI服务器，一旦检测到源码发生变化时，它就会从Subversion代码仓库中获取最新代码，并运行Ant构建脚本。

        作者Andrew Glover将如下三项作为了典型CI环境设置的主要组件： 
        一个使用构建工具（如Apache Ant）的自动化构建过程。 
        像CVS或Subversion之类的源码仓库。 
        CI服务器，如Hudson。 
        Andrew用了一个java应用为例，讲述了如何在Hudson服务器上配置java项目，从而运行自动化构建。他还展示了如何通过Hudson的插件扩展将类似于FindBugs和PMD的代码分析和软件检查工具进行集成。

        在 文章中，作者阐述了如何使用Hudson来捕获构建过程的执行时间和测试结果所反映的趋势。在每一次构建中，CI服务器都会对JUnit结果的XML文件 进行解析，并生成一个趋势图，用于展示在相邻的两次构建之间，增加了多少个测试。同时，它还可显示出测试是否通过（蓝图表示通过，红图表示失败）。通过 PMD或者FindBugs发现的代码冲突或是缺陷，都会在每一次构建后被记录下来，以供历史分析。 
        还可以为Hudson配置一个SMTP服务器，从而在构建失败时向整个项目团队发送邮件提醒。它还支持使用RSS作为提醒机制，开发团队可以通过RSS feeds来订阅项目的构建状态页面。

        Hudson同时支持JUnit和TestNG这两种测试框架。它还可以与其它SCM工具（如CVS，ClearCase或Accurev ）和构建工具（如Maven和Gant）进行集成。在Hudson网站上列出了所有的插件，我们可以看到，它可以和众多的开源或是商业的SCM、代码覆盖和问题跟踪工具进行集成。

        在developerWorks上的另外一篇有关CI话题的文章中，Paul Duvall向读者展示了在建立CI环境时的一些最佳实践，并指出如何避免一些错误做法（他把它们称之为CI反模式）。这些最佳实践是：

        开发者应该频繁提交小段代码，而不是等上很长时间以后，一次性的提交很多变化； 
        当构建失败时，CI服务器应该立刻通知项目团队； 
        应当使用类似E-mail或者RSS之类的反馈机制来与项目团队报告构建状态； 
        构建状态反馈应该简洁，只应该包括与构建相关的信息； 
        构建服务器应该有足够的硬件配置，从而进行更快的构建； 
        项目团队应遵循“管道式构建”的原则来异步执行那些需要较长时间才能运行完的构建过程。