“持续集成”之一二三

自动化测试是持续集成的前提

毋庸置疑，自动化测试是持续集成的前提。

如果您的项目还没有单元测试或功能测试代码，那么持续集成的意义就不那么重要了。只有随着项目的进行，不断增多的自动化测试，才能突显持续集成的重大意义。持续集成是代码健康状况的指示器或风向标。通过持续集成，可以尽早发现问题，提醒团队成员尽早修复问题，得到更健康的代码。

持续集成有很多实践，通过实际项目的经历，总结三个基本实践：

一、尽早开始

持续集成应该在项目初始阶段就给予考虑，并在搭建开发环境的同时建立持续集成环境。而且，你最先check-in的代码文件应该包括你的构建脚本，从而触发第一次构建，并使这次构建通过。此后，你所需要做的就是不断增加代码，改进构建过程。

有人可能会说：“刚开始时，代码那么少，大家工作在不同的功能模块上，冲突不多，自己手工运行一下测试不就行了，等以后再建持续集成环境吧。”
其实，很多时候一旦说“等以后”，那就等于说“Never”。就象单元测试一样，“开始时代码这么简单，不用测试也没问题；而当认为代码不那么简单需要测试时，就会发现此时单元测试太难了，要重写好多代码，还是不写了吧！”结果可想而知。

所以，持续集成还是在项目最简单的时候引入为好。

二、尽快运行

持续集成最主要的目的就是得到尽早的反馈。项目开始时，代码较少，持续集成所用的时间不会太长，只有几分钟。对于开发团队来说，这个时间还可以忍受。可是，随着代码库的不断增大，功能增多，持续集成所花的时间越来越长，以至于影响开发团队的生产力。一定要在此之前再去优化你的持续集成。因为当你意识到这个问题的时候，它已经产生了负面影响。那么如何让持续集成尽快运行呢？

一般来说，有三种途径可以达到：（一）优化代码，即通过对现有代码的优化使运行更快，如尽可能地减少外部依赖，使用内存数据库代替基于文件系统的数据库等；（二）纵向扩展，即通过增强持续集成所需硬件的性能［如内存，CPU］等提高运行速度；（三）横向扩展，即通过将测试分成多个部分，在多个环境下并行运行后汇总结果，以达到节省时间的目的。

三、专人负责

在项目中，要有专门的人员或角色（CI engineer）来负责持续集成的改进。只有某种任务有相应的责任人后，该任务的执行才能得到保障。这一点在较大或较复杂的项目中尤其重要。

因为在项目较小，人员较少的情况下，大家可能会对持续集成的环境都非常了解，只要有问题发生，都会找到问题，加以解决。但是，在较大较复杂的项目中，持续集成环境可能会比较复杂，持续集成的服务器以及构建机在哪里，有什么样的配置，如何管理不可能被所有的项目成员了解。此时，就该CI engineer出现了。他的责任就是尽可能地利用资源使持续集成的周期缩短，使反馈更加迅速。

当然，这并不是说，有了CI engineer，持续集成的结果就由他负责。对于持续集成中的失败，所有团队成员都有责任有义务去fix，即使自己不能fix，也要找到正确的人去fix。

当然，这并不是持续集成的全部，只是持续集成的基本实践。只有做到了这三个基本实践，才能高效地发挥持续集成的作用。