基于 CruiseControl 和 Rational 统一变更管理实现的软件开发中的自动化持续构建

核心提示： 单元构建为了达到尽早发现问题的目的，我们设计了单元构建，基于 CruiseControl 和 Rational 统一变更管理实现的软件开发中的自动化持续构建(2)，单元构建是基于前一次成功构建，仅对修改的源代码进行编译和单元测试的构建过程，所以需要较长时间完成，为了不占用白天的服务器资源， Cr

单元构建

为了达到尽早发现问题的目的，我们设计了单元构建。单元构建是基于前一次成功构建，仅对修改的源代码进行编译和单元测试的构建过程。 CruiseControl 提供的与 ClearCase 集成的功能可以监控 UCM 项目的集成流，当基于变更请求的代码被交付到集成流，新的元素版本在流上被创建，CruiseControl 这时启动单元构建程序。这个构建可以采用增量编译，目的在于迅速发现被交付的代码与集成流上的代码归并后是否存在错误。当然有些问题只有在完全编译中才能被发现，但是考虑到这种问题如果不是经常发生，而且为了达到短时间完成单元构建，然后可以对其他被交付的代码进行检查的目的，我们可以将完全构建发生的问题留到每日构建中解决。此外，为了尽早发现集成的代码中存在的问题，也可以在构建脚本中加入基本的自动测试脚本。脚本中的任何测试用例的执行失败都会直接导致单元构建失败。

图 1. 持续集成中单元构建的典型流程

每日构建

不管是使用敏捷开发还是瀑布开发模式的项目，最好每天至少完成一次完全构建。和单元构建相比，每天进行的完全构建产生可以用来测试和发布的 artifacts，并且在统一变更管理系统中创建和维护基线，记录当前构建是否成功。通过基线，开发人员可以回溯项目的历史版本重新建构历史发布，也可以重构失败构建的代码环境来分析和解决问题。和单元构建一样，在构建 artifacts 产生后，也可以在构建脚本中加入基本的自动测试。如果自动测试中的任何测试用例执行失败，那么每日构建也标记为失败。由于每日构建是完全构建，并且调用的测试用例可能也比单元构建多，所以需要较长时间完成。为了不占用白天的服务器资源，我们可以设定在晚上的某一时间启动每日构建。