Continuous Integration - Why need it?
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage. -- Martin Fowler
开场用老马的话来引入持续集成的概念。作为一个系列Camp，首先介绍下为什么需要持续集成。
为什么需要持续集成：
在传统软件（瀑布模型）公司做过开发的朋友应该都清楚，软件开发的流程大致分为：
需求定义——系统分析——概要设计——详细设计——编码——测试——部署
等几个步骤。一般情况下只有再软件测试完毕后客户才能拿到自己“想要”的产品。而这里面却隐含了两个问题：
首先，什么时候软件才能测试完毕？这个通常随着项目的周期长短而不同，或者若干个月，或者一年半载甚至更长。也就是说，只有在用户提出需求后的很长时间后，他们才能看到软件。
其次，数月后产生的东西真的是用户“想要”的产品吗？未必，或者更极端说一定不可能。这可以从两个方面进行解释。
-
不同人多相同事物的理解是不一致的。即便充分沟通后，也有可能对一些概念产生曲解。比如在结对编程中有一种Drive-Watch的模式，这通常在一个经验相对丰富的人和一个经验相对较少的人pair时采用。通常人们都会将该模式理解为经验丰富的人来Drive（写代码），经验较少的人来Watch(观察学习)。其实不然。事实上Drive-Watch对象指的都是经验丰富的那个人，而他主要负责指点新人编程，而不是代码都由他来写。类似于这种被称为common sense的概念如果开始时就被曲解，而没有提前发现，就很有可能在今后逐步积累成更大的错误。同理，软件开发过程也是一样的。如果我们开始对需求的理解有就错误（事实上不可能没有错误），尤其是一些概念的理解偏差，而这种错误没有及时暴露出来，后续很多功能又都是基于该概念的。那么最后出来的软件质量可想而知。
- 人对事物的理解是渐进的。在面对一个庞大而复杂的系统时，人脑很难对它有一个完整且清晰的认识。客户提需求也是一样，软件交付之所以困难，其中很大一部分原因就是因为需求的不断变化。而这种变化是贯穿在整个软件开发过程中，或者说，需求变化本身就是软件开发过程的组成部分。当采用瀑布模型开发时，这种变化也只能在数月甚至数年后测试结束时才能反映出来。
相信做过传统软件开发的朋友，在这两点上都或多或少的被瀑布模型刺痛过。那么有没有一种开发模式能解决上述问题呢？答案当然是肯定的——持续集成。
开始持续集成：
定义
从狭义上来说，持续集成是指持续集成工具，市场上包括Hudson,Cruise,Go等，该类型工具可以监听代码库的改动(ChangeSet),并且根据预定义的脚本来执行测试、构造等活动。以达到快速反馈的目的。
从广义上来说，持续集成就是敏捷开发，它不仅有上面提到的狭义定义，还贯穿整个软件的开发流程，包括团队组织模式，Story划分,Pair Programming，TDD，重构，代码集成策略，以及部署等等。
版本控制系统（VCS）的比较与选择
现在市面主流的版本控制系统包括SVN, Mercurial Hg,Git,ClearCase,VSS等等。
Hg与Git 属于分布式版本控制系统(DVCS),适合分布式团队开发。同时他们会在本地存一份完整的Repository,因此提交速度也相对较快。支持多人同时修改同一个文件（需要手工或自动Merge）。
SVN的Repository在远程，因此提交代码或者查看文件修改历史时会相对较慢。也支持多人同时修改同一文件。
ClearCase与VSS的Repository在远程，修改的提交是基于文件而非ChangeSet，因此提交速度最慢。并且不支持多人同时修改同一文件。
在代码所有制为集体的前提下，推荐使用SVN或者HG/GIT。这两类工具可以更好的提升团队的开发效率。
