在理解一个新的东西时，我们首先要去了解下它的概念。
概念
持续集成（英语：Continuous integration，缩写为 CI），一种软件工程流程（即，开发流程），将所有工程师对于软件的工作复本，每天集成数次到共用主线（mainline）上。
这个名称最早由葛来迪•布区（Grady Booch）在他的布区方法中提出，但是他并没有提到要每天集成数次。之后成为极限编程（extreme programming，缩写为XP）的一部分。在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。
持续集成的提出，主要是为了解决软件进行系统集成时面临的各项问题(版本冲突等问题)，极限编程称这些问题为集成地狱（integration hell）。
在了解到持续集成的概念（一直不断在项目主线分支上开发）后，我们来看看我们为什么要做持续集成呢，做持续集成有什么好处呢？
为什么要做持续集成
持续集成在目前大多数的公司里都会有这样或者那样的使用。有的会选择一些Open Source的工具，如CruiseControl，Hudson，LuntBuild等等等等，有的会购买有更好服务，更强功能的商业产品，如TeamCity，QuickBuild等等，而有的会选择自己实现，如Cron+Ant/Maven/Make等等。那么使用下来效果如何呢？真得达到了预期的效果吗？我想来恐怕未必吧，否则也就不会有这么多的讨论了。
它的好处主要有两个。
- 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
- 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
Martin Fowler（不要告诉我，你不知道大名鼎鼎的Martin叔，提示，IOC和DI那篇文章）说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。"
与持续集成相关的，还有两个概念，分别是持续交付和持续部署。
持续交付
持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续部署
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。
在了解到做持续集成的好处之后，那么我们怎样来做持续集成呢？首先，我们得要有一台（或好几台）服务器用来做持续集成。
持续集成服务器的选择
在进行持续集成实践前，应当正确的选择并配置持续集成服务器。比较成熟的持续集成服务器包括：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之类的工具啦。
总结
持续集成只是软件开发的一种方式而已，虽然好处挺显而易见的，但是能够很好实践的团队不知道又有多少，我们只有在开发的过程中不断总结适合自己团队的开发方式，把项目完成即可。
