持续集成

    前面已经提到，重构story也同样应该是可验收的。除了确保其功能性行为仍然保持原样不变之外，这类story还有更多的验收条件：单元测试覆盖率、代码复杂度、编码规范等指标都应该符合项目要求。这些指标也同样适用于新功能开发的story。这些指标的报告应该自动化地生成，及时地展现给所有项目成员，为此我们需要一个持续集成环境。

    eMAN项目采用CruiseControl作为持续集成工具。每次开发者往代码库中签入（check in）代码时，就会触发CruiseControl对项目进行构建，构建的内容包括编译、连接（对于后台部分）、单元测试、测试覆盖率统计、代码复杂度统计、编码规范检查、部署到测试环境、功能测试等。由于前台运行在Windows上而后台运行在Linux上，我们用两台持续集成服务器分别构建前台与后台，然后再把两者集成起来进行功能测试。

    在建立持续集成环境的过程中，我们发现eMAN项目以前缺乏有效的项目自动化（automation）机制。虽然前后台分别有一些脚本用于执行编译、部署、启动应用等常规任务，但项目自动化机制还有较大的欠缺：

    缺乏版本控制。原来的版本控制库中只有项目源代码和运行时配置文件，开发阶段的配置和自动化脚本都不在版本控制中。

    环境依赖。原来的自动化脚本对操作系统、安装的软件环境甚至项目路径等因素都有依赖，每个开发者从版本控制库获取代码之后还需要复杂的配置才能让系统在本地运行。

    自动化不彻底。原来的自动化脚本没有覆盖到构建的所有环节，并且各个环节之间没有连通，开发者必须执行多个步骤的操作才能完成构建。

    在这样的自动化脚本基础上，持续集成环境无法发挥出它最大的价值，因此我们对自动化脚本做了一系列改进，达到的效果是：只要在一台干净的机器上安装Java和Ant，然后从版本控制库签出（check out）项目，在项目目录里执行ant即可完成整个构建。于是完整的构建不仅在持续集成服务器上频繁运行，还在每个开发者的工作机器上更加频繁地运行。

    在这个过程中我们用到的工具（前台部分）包括：

    持续集成服务器：CruiseControl

    项目自动化工具：Ant

    测试覆盖率和代码复杂度统计工具：Cobertura

    代码风格监测工具：Checkstyle