持续集成这篇文章已经准备了挺长时间，鱿鱼很多原因没有动手写来来，嘻嘻。
持续集成其实包括几个概念：持续集成、持续交付以及持续部署，环环相扣的一种运作方式。
持续集成
持续集成急频繁地(至少一天一次)将代码集成到主干，通过自动化的构建(编译、部署、测试)来对新交付的代码进行功能以及整体的测试。由于项目组的每一个开发成员每一天都需要提交代码，因此需要每天都更新本地的代码(svn，git)。
这样频繁的交付代码，有什么好处呢？第一点即可以尽早发现Bug。如果项目没有及早进行测试，而是程序员进行单元测试之后继续敲下一个功能模块的代码，等到上线前最后一两周才交给测试组测试，那么潜在Bug的数量与影响是不可预计的。持续集成可以有效地避免这种情况，每日集成将风险控制在可接受范围内。第二点增加项目可见性，可见性是基于两个方面的，一方面是为项目提供有效决策，另一方面是能为团队提供有效的项目趋势。有效决策，即持续集成为项目构建状态和品质提供了及时地信息，依据这些信息，团队leader可以及时进行调整：设计调整、功能点、测试、部署等。项目趋势，由于经常集成（一天多次，比如团队有10个开发，则一天集成10次）可以体现出项目的一些基本趋势，build成功还是失败，以及对应的次数，总体品质等等。
持续集成要求的关键词有很多，比如统一的代码库，自动化测试，自动化部署，要求开发团队成员每天提交代码等等，无一不体现着“持续”二字。
持续交付
持续交付也有一个核心思想，主干代码一直处于可以交付的状态。这样意味着，主干代码能通过各种测试、质量有保障。持续交付作为持续集成的一个重要部分，要求频繁交付，供测试团队or用户进行评审。
持续部署
持续部署这一动作发生在持续交付之后，此时代码已经通过测试团队or用户的评审，功能、质量达到了上线的要求。
整体流程似乎也体现了敏捷的思想，个人感觉和敏捷天生是一对，嘻嘻。
