自动化

　　现在你已经可以在任何一台机器上自动构建你的产品了，那么让我们来使它自动化吧。

　　自动化的目标是自动化整个构建，在一台干净的机器上，在测试周期内，使人为干预最小化。使万事自动化并非都有可能。但是我们希望达到的目标是，把那些可以被合理的自动化执行的东西都写入脚本。

　　有时，安装和配置一个软件要比编写一个脚本来自动安装和配置更为容易。只需一次性安装的应用程序当然是首选。诸如编译器，运行库和已存的数据集都属于这一 类。不要试图花费两个小时去复制已存的数据集。但是，如果你能在30秒内重建一个代表性的数据集，那么你便应该从头开始。以一个干净的已知的数据集开始的 好处非常大，但是并非总是符合实际。不要因为重建你的数据，将15分钟的测试变为一个小时。

　　要确保记录下任何一个手动步骤及所有指令，它们可以为其他想复制运行环境的人提供帮助。

　　另一方面，为什么你应该整天监视着全部的构建？时间是宝贵的。IDE或多或少都是可以进行增量构建（incremental build）和运行细粒度单元测试（small unit test）。很多时候，这种部分覆盖（partial coverage）已经够用了。让开发人员针对活动的代码区域（active code area），运行一组冒烟测试（smoke test），就可以覆盖大多数情况。

　　冒烟测试

　　冒烟测试是一个简短的测试集合，其目标是被频繁修改的代码区。冒烟测试不必设法运行整个产品。一套好的冒烟测试应该是可以轮换运行的……它们不 是永久不变的。当你开始致力于不同的产品领域时，退出原来的冒烟测试，把新的测试添加进来。你可以从完整的测试套件中选择恰当的测试，使其在冒烟测试套件 运行。我通常都是把它们添加到一个Ant target（我把它命名为smoke-test）中，然后运行选定的测试。

　　我们仍然需要一个干净的构建和周期性运行的完整测试。这就是我们如何验证是否有人忘记提交一个被修改的文件或者用一种非预期的方式来破坏产品。冒烟测试经常遗漏这几类破坏，为了保持产品处于最佳状态，我们需要相当频繁地运行整个测试套件。

　　不 要要求每个开发者从头构建整个系统，也不要每天运行五遍每个可用的测试。相反，那些需要花费一些时间来执行的任务，我们都该让计算机来替我们完成。因为我 们可以给计算机分配任务来执行自动构建和自动运行测试，所以我们没有理由每周不运行超过一遍。事实上，每个代码改动后也没有理由不运行一遍。

　　建立这类自动化的最佳方式是什么？最快捷、最容易的方法就是使用一个持续集成（CI）产品。CI产品可以监视你的代码，在每次修改后构建，运行测试，然后通知所有相关人员。

　　持续集成图

　　CI系统会创建一个快速反馈循环。当你修改代码时，如果代码遭到破坏，你就会在忘记为什么修改它之前发现它。（关于CI系统的更多信息，请访问我的CI页面 http://www.jaredrichardson.net/ci.html）。

　　所有这些讨论都是关于开发速度和持续不断的进度的。对于保持团队的进度，回顾上周或者上个月所编辑的代码是一条末路，而在数小时内抓住并且解决问题才是真正的解决之道。