持续集成：什么应该自动化？

持续集成：什么应该自动化？

一、什么是持续集成（Continuous Integration）？

这个名词已经在软件开发领域持续了N年，一个比较简单的定义如下：
持续集成（CI）是一种实践，可以让团队在持续的基础 上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。通俗一点儿说，就是指对于开发人员的每一次代码提交，都自动地把Repository中所有代码Check out到一个空目录，并且自动运行所有Test Case。如果成功则接受这次提交，否则告诉所有人，这是一个失败的Revision。更具体的解释可以参考Martin fowler的Continuous Integration  。

二、持续集成的价值与成本

有句时髦的话，叫做“存在即为合理”。既然持续集成已经存在了这么长的时间，而且没有消失的迹象，那就是有价值的东西。那么它的价值何在？有人概括如下：(1) 减小风险；(2) 减少手动过程；(3) 生成构建结果；(4) 安全感。
而持续集成的成本在于对持续集成代码的维护成本和集成的时间成本。因为随着项目进行，软硬件环境会越来越复杂，成品代码也会不断膨胀。此时，需要团队而修改或增加原有的测试代码，以适应这些变化，同时，每次集成所需时间也会变长，这就是持续集成的成本。某个blog中提道：“这种集成是如此的频繁，多少次的代码Commit就有多少次持续集成。前提是集成的成本很低，或者说是完全自动化的。”

三、持续集成应该自动化什么呢？

我们要以尽可能少的成本来获得尽可能多的价值。这就要考虑哪些自动化是必要的啦。Jez Humble提到至少有六点要做到自动化，它们分别是(1)自动化的运行测试；(2) 自动产生可部署的二进制成品；(3) 自动将成品自动部署到近似生产环境；(4) 自动为CodeBase打上标签；(5) 自动运行回归测试；(6)自动生成度量报告。

四、持续集成服务器的选择

在进行持续集成实践前，应当正确的选择并配置持续集成服务器。比较成熟的持续集成服务器包括：CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。CruiseControl作为开源产品，以其对于各种SCM以及构建工具的广泛支持而被许多开发团队所接受。而开发自动化专家 Duvall 采用一致的评估标准和很多说明性示例，介绍了一些开源 CI 服务器，包括 Continuum、CruiseControl 和 Luntbuild。并指出“要根据 自己的 具体技术和政策需求对工具进行分析”。并用以下五个指标来评估CI工具，它们分别是：(1)  特性；(2)  可靠性；(3)  寿命；(4) 目标环境；(5) 易用性。结果如下表：


而CruiseControl是我唯一真正用过的持续集成工具，它现在灵活而又强大功能也让我瞠目，而且配置与管理也较两年前容易得多啦。为什么说它强大呢？因为你只要想得到的问题，它也都会有所考虑。朋友的Blog上有些CruiseControl的最佳实践足以证明这一点，只要你肯去实践。

五、只有持续集成服务器是远远不够的

正如Jez Humble所说，CruiseControl和其它的CI工具本质上只不过是一个定时器，时间一到，做你让它做的事情。所以，必然要有其它工具与其结合，方显持续集成的本色。这些工具又是什么呢？想测试的话，你就要用一些测试工具，如JUnit，JWebUnit，Selenium等等；想检查代码标准的话，你就要用checkstyle等代码规范检查工具；想要了解测试覆盖率的话，你可能就要用到JCoverage啦。当然，想得到二进制文件，就要用到Ant，Make之类的工具啦。

六、最重要的事：实践与反思

也许这些东西大家都知道，而且有些人可能已经实践过啦。无论这些实践的结果是怎样的，一定不要忘记总结和反思。如果这些实践成功了，不要把它归功于这个工具，而是要总结一下为什么会成功，如果你愿意的话，还可以和大家分享一下。如果这些实践失败了，也不要把它归功于这个工具，而是要反思一下，是否正确地使用了这个工具，团队成员是否都喜欢这个工具，为什么？