持续集成

在敏捷团队待过一年多，所有的敏捷实践方法差不多都接触过，持续集成尤令人推崇喜爱。记起几年前的一天中午，熊节同学给办事处所有同事发了一封邮件，内容是关于持续集成在项目中的应用，读后拍手称赞，仿佛得一利器。而里面的内容也记忆犹新.

在吹鼓持续集成前，我先讲述以前我所在团队中的一些情况，当然都是相当糟糕的事情。我在的团队有二十多个人，开发人员有十多个，那个时候做电信的CRM子系统。大团队给我的感觉是：人员能力参差不齐，沟通效率低，反馈不及时。新员工对系统不了解，我们也缺乏一些常有的知识传递，经验共享的资料。而我们的代码让我是真心的觉得烂，一个方法里面我见过有千行代码的，内容很丰富，却不容易让人吸收。新员工如果要改代码，要么看不懂不敢改，要么改了引起另外的问题，有时我也想过做重构，可看到那庞大的方法，以及没有可用的测试用例我就怂了。于是也养成了一个不求有功，但求无过的心态，代码就这么放着吧，不出问题能跑就行，代码之美那本书又被我扔到脑外。对于我们的代码，那时其实我知道问题出在哪，除了员工能力不说，团队中缺少一个快速反馈的机制，这种反馈机制是对当前代码的健康状态的检验。比如，开发人员在提交代码时，如果少提一个文件，那么可能导致整个编译都失败。但是这种错误往往要到最后发包时才会发现。再比如，开发人员的代码有对本地（特定环境）有某种依赖，而提交代码时却忽略了这一点，而当别人更新代码时发现不能用，但问题很难定从位，因为在更新代码前，有许多人都上传代码了，不能准确的知道是谁的代码出了问题。这些问题都是我切身经历过的。有过深受其害的感觉。

后来团队在做敏捷时，引进了持续集成这个概念（持续集成是敏捷方法里的重要一个），让我这个乡下来见识到了这个工具（实践）的强大。我对它的理解是：通过频繁的构建，快速的反馈代码的当前状况。

Martinfowler的述说是这样的:持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成会经过自动构建（包括自动测试）的检验，以尽快发现集成错误.

下面我将详细的介绍持续集成

基础持续集成模式:

（图片来自IT168）

看到上图，上面是一个最简单描述持续集成的图形，持续集成其实也很简单，一台持续集成服务器+持续集成工具（Hudson或CruiseControl都是开源的）+构建脚本（这里可以做代码规范检查，圈复杂度，findbugs，测试用例运行，.....编译，打包，发布），它的原理是这样的：每当开发人员提交代码到配置库中（cvs,svn,git）,持续集成工具运行构建脚本,进行构建，并生成报告（以html,xml,发收邮件）.,看下图:

(图片来自IT168)

看，其实多简单，但是，以我个人的经验，我知道，在一个团队对持续集成没有了解的情况下，如果要加入这一实践其实还困难重重，接下来，我将描述一下持续集成的优点与缺点。

优点：正如我上面所说，持续集成是一个快速反馈的机制，它能反应当前代码的状况，并且这些检查都是自动化的。可以从开发人员角度带着两个问题来思考：1、我提交的代码能正常工作吗？2、我修改某段代码后，可行吗？如果借用持续集成，则这些顾虑则无需担心。

那么可能会有另外一个问题。持续集成就真的能保证上面两个问题不是问题，或者是不是太虚了？带着这个问题我来讲述一下持续集成的“缺点”，其实缺点来形容是不贴切的，可以改为：瓶颈;

为了能够快速定位构建的失败的原因（我们不能保证每次构建都是成功的），那么在做持续集成时会要求开发人员提交代码时不能并发提交，开发人员一旦发现持续集成环境在构建，那么要求等待本次构建成功后，才能提交代码。这样便于万一出现问题可以快速定位到，并通知相关的开发人员进行修改。一个新团队在刚做这样实践时往往会觉得提交代码受到限制而苦恼。所以这要求持续构建的时间要尽量短，最大控制在十五分钟以内，这对于一个新起的，没有技术债术的项目来说是很容易做到的。还有一点是，为了保证代码修改后的正确性,没有引发其他的错误，那么需要有可用的测试用例。但是我知道许多团队里面没有测试用例，就算有，也不能很好的利用。测试用例的好处除了在当前开发时保证方法是可以用的之外，还为日后的代码修改，重构（在不改变软件的外在行为下，对代码进行修改，提高代码的质量）打下基础。但是写测试用例是需要时间的，这也是为什么许多团队不写测试用例的原因。很多人认为写测试用例是浪费时间的，但是从长远的角度来看，写测试用例是有必要的。这种内功只有随着时间推移才能体现出其的优越性。回想自己当初不敢改别人代码时的尴尬，要是别人在再初写这个方法时已经留下了测试用例，后来者又有什么顾虑的呢？而当初写测用例的时间比起后面的问题定位花的时间又算什么呢？持续集成的还有一点瓶颈是要求队团人员有共同的意识，比如代码的编写规范，对测试用例的爱护等。而这种意识形成一致是需要一段时间的磨合，试想一下，每个人的编码风格不一样，变量命名不一样，方法长度不一样。一旦要求团队保持一致，大家都觉得被束缚了。我以前在做时经常在提交代码时检查出一个findbugs，而这个问题是因为我的方法首字母大写，于是我还得改掉，包括调用处都要检查。我也会觉得很郁闷，不过想想大家都是为了代码的质量也是可以接受。但这不是每一个团队都能接受，工具的传递，要看与被接受者能否达成共识。没有达成共识就算勉强接受最后也变成累赘。

Martinfowler(熊节译):http://news.csdn.net/n/20050511/21164.html

乔梁:http://www.infoq.com/cn/news/2011/01/ci-check-in-dance/