每当团队成员向版本控制存储库提交更改时，代码就会发生改变。但它是怎么改变的呢？被修改的代码是受到复制-粘贴工作的影响吗？复杂性会增加吗？了解这些的惟一方式就是在每次签入 时都运行软件检查器。此外，在持续的基础上接受目前为止讨论过的每种风险的反馈，这是一种自动 让代码基进行健康检查的一种可靠方式！
CruiseControl 是 Java™ 社区使用最广的开源 CI 工具之一。这个工具被配置成在后台运行，用于检索版本控制存储库，例如 CVS。在发现源代码更改时（例如，有人签入了代码），CruiseControl 就会执行源代码签出，并运行预定义的构建脚本。
所以，只要 版本控制存储库中发生了变化，团队就可以运行 CheckStyle、CPD 和 JavaNCSS 这样的软件检查器。这种能力允许团队长时间地进行监视和执行检查，通过使用许多 CI 工具，团队可以使用报告、电子邮件甚至使用 Ambient Orb 这样的设备生成报告（参见 图 5）。
清单 5 演示了使用 CruiseControl 的配置文件（通常名为 config.xml）在 CruiseControl 控制板上显示 CheckStyle 报告的结果。其他软件检查器使用类似的语法将结果合并到 CruiseControl 仪表板中。
清单 5. 在 config.xml 中用 CruiseControl 记录 CheckStyle
<listeners> <currentbuildstatuslistener file="logs/${project.name}/status.txt"/></listeners><modificationset quietperiod="30"> <svn RepositoryLocation="http://www.qualitylabs.org/svn/ambientorb" username="[username]" password="[password]" /></modificationset><schedule interval="60"> <ant anthome="apache-ant-1.6.5" buildfile="build-${project.name}.xml"/></schedule><log> <merge dir="merge dir="checkout/${project.name}/_reports/checkstyle" /></log> |
图 4 显示了用 CruiseControl 和 CheckStyle 生成的示例报告。请注意，可以配置 CruiseControl，显示其他工具（像 CPD 和 JavaNCSS）的报告，而且通过对每个源代码更改 都运行这些报告，团队可以实时地积极改进代码，不必等到周期末期。
图 4. 与 CruiseControl 集成的 CheckStyle 报告
对于使用 CI 工具持续运行软件检查器而言，最酷的事就是团队有了无数任意使用的通知机制。有时，构建可能并没有失败，但是有些事 的变化要求早些而不是晚些采取纠正行动。例如，实际上可以很容易地配置一个设备（就像 Ambient Orb），在代码复杂度有所上升时，或者在违反一定数量的代码标准时，使用该设备改变颜色。
清单 6 使用了 Ambient Orb Ant 任务和 Ruby 脚本，在 20 个以上的类超过 300 个源代码行（SLOC）时，就改变 Orb 的颜色和动画。在这个示例中，我选择在类满足条件时将 orb 的颜色改成 magenta，将动画改成 crescendo。
清单 6. 委托 Ant 构建文件处理 CruiseControl 和 Ambient Orb
<target name="checkSloc" > <exec dir="${basedir}" executable="cmd.exe"> <arg line="/c ${config.dir}/javancss/SlocThreshold.rb ${reports.javancss.dir}/javancss_metrics.xml 20 ${javancss.file}"/> </exec> <available file="${basedir}/${javancss.file}" property="sloc.exceeded"/> <antcall target="notifyOrb" /> </target> <target name="notifyOrb" if="sloc.exceeded"> <taskdef classname="org.qualitylabs.ambientorb.ant.OrbTask" name="orb" classpathref="orb.class.path"/> <orb query="http://myambient.com:8080/java/my_devices/submitdata.jsp" deviceId="AAA-9A9-AA9" colorPass="green" colorFail="magenta" animationPass="none" animationFail="crescendo" commentFail="SLOC+Exceeded" /> </target> |
图 5 演示了代码基中有太多较大的类时，orb 看起来的样子：
图 5. Ambient Orb
使用这种 Ambient Orb 通知方法，就不会收到无穷尽的电子邮件，只要看一眼 SLOC Threshold Orb，就可以快速了解我有多少个大型类，它们提醒我要重定向重构工作。当然，组合 ambient orb 与软件监视器（稍带些创意）也会创造无穷的可能性！
请记住，可以选择许多不同的软件检查器。虽然这里分析了三个我喜欢的软件检查器，但我还是被 JDepend、PMD 和 FindBugs 工具（后两个检查器在 developerWorks 上已详细讨论过）所打动。一旦开始持续检查过程，插入一个新的检查器只是几分钟的事而已。
持续检查不会也不应该消除手工软件检查；但是，通过对版本控制存储库中的每个更改都运行一套自动检查工具，将要执行的 这些手工检查会带来更高的生产率和效率。而且，持续检查带来的额外好处有：风险在每一步上都可以降低，而不必等到项目后期。
下一个月，我将深入研究一些更有趣的持续集成工具，例如 CruiseControl、Luntbuild 和 Continuum，并让您确定哪一个工具最适合您。自动化从未 这么有趣过！
文章来源于领测软件测试网 https://www.ltesting.net/
