再释“持续集成，应该自动化什么？”

持续集成是敏捷最佳实践之一，但并不是只有使用敏捷方法的团队才能够采纳。但如果你能够采纳敏捷方法，那么它会发挥更大的作用。

“什么是持续集成”在前面的文章中已谈过了，这里只把其中的一部分：持续集成的六个基本自动化再细说一下。这六个基本自动化是：自动运行测试、自动产生可部署的二进制文件，把它部署到类似生产环境中，自动标识你的代码基线，自动运行回归测试以及自动产生度量。

一、运行测试
　　这本来是不必说的事情，但还是有很多项目，其持续集成过程只是去编译一下代码，就不做别的了。可在持续集成过程中的绿色应该表示的是可以工作的软件 – 可没有自动化的测试，你哪会有信心呢？一套好的测试应该尽可能多地覆盖到所有代码，而且运行也要尽可能地快（也就是说，你的最主要的那个构建应该不超过10分钟），同时不要依靠于其它基础环境（如数据库或消息通道）。
 
二、产生可部署的二进制代码
　　 它可以是一个能部署在Web应用服务器上的jar包，也可能是一个MSI安装文件。无论你用哪种方法安装你的软件，持续集成过程都要做打包工作并最终生成这个东西。这样，测试人员就可以从持续集成工具的页面上直接下截这个安装包来测试了，这样就减少了从检入代码到知道代码可以工作之间的反馈时间。持续构建所产生可部署的二进制代码也意味着它是被不断测试的，以免最终产品上线时遇到麻烦。

三、部署你的产品到与生产环境类似的环境中
　　 让你的产品能在非开发环境中运行通常是项目比较困难的问题，特别是产品需要部署在非常复杂的环境时。而使你的部署过程自动化并把测试这一过程也作为持续集成的一部分，会缓解这些问题。而且，这也 意味着你的测试人员更易于在真实环境中测试你的软件——这样，对你的软件真的可以使用更有信心了。

四、标识你的代码基线
　　SVN这类版本控制工具是支持原子提交的，它们可以将开发人员的每次检入都用版本号打上标识，但象CVS这类版本控制工具就不支持原子提交。另外，你的源文件也可能分散在不同的代码库中。所以一定要自己在持续集成过程中把每一次构建都打上标识。这样，一旦在测试中发现问题，你就可以追溯到正确的版本来修正它。

五、运行回归测试
　　如果你有运行时间比较长的接受性测试或回归测试，最好也把它们自动化起来，并进行周期性的运行。由于它们运行时间会比较长，所以可以不放在主构建中，否则就会影响主构建的反馈速度。但是，至少每天晚上你都要运行一次，如果可能的话，间隔时间可以再短一点。这不但可能给你额外的信心，而且还可能确保你一直在更新你的回归测试或接受性测试。当代码发生变化后，这种接受性测试很容易失败，因为这些代码不再反映需求了。

六、产生度量数据
　　 你要小心处理“度量”这件事，因为它对你的开发人员有很大影响。度量代码的测试覆盖率就是常持续集成共同使用的常见度量方法——但用它也很容易导致开发人员写出无用却可以提高覆盖率的代码。可是，如果你的团队都能接受这些的话，那么使用代码覆盖统计、代码式样检查、依赖分析等方法可以促使开发人员不断地改进代码质量。

当然，还可以做其他自动化工作，如生成文档、产生数据库脚本等等。但是，如果最基本的自动化都做不到，那其他事情就不用做了。

原文见链接