刚开始时 我对这个概念很狭隘 以为只要能让系统自动下载代码然后编译通过就叫持续集成，其实不然 我们仔细学习下基础概念。
持续集成（Continuous integration）
集成
软件的过程不是新问题，如果项目开发的规模比较小，
比如一个人的项目，如果它对
外部系统的依赖很小，那么软件集成不是问题，但是随着软件项目复杂度的增加（即使增加一个人），就会对集成和确保
软件组件能够在一起工作提出了更多的要求-要早集成，常集成。早集成，频繁的集成帮助项目在早期发现项目风险和质量问题，如果到后期才发现这些问题，解决问题代价很大，很有可能导致项目延期或者项目失败。
大师Martin Fowler对持续集成是这样定义的:持续集成是一种
软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，
自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发
内聚的
软件。
减少风险
一天中进行多次的集成，并做了相应的测试，这样有利于检查缺陷，了解
软件的健康状况，减少假定。
减少重复过程
减少重复的过程可以节省时间、费用和工作量。说起来简单，做起来难。这些浪费时间的重复劳动可能在我们的项目活动的任何一个环节发生，包括代码编译、数据库集成、测试、审查、部署及反馈。通过自动化的持续集成可以将这些重复的动作都变成自动化的，无需太多人工干预，让人们的时间更多的投入到动脑筋的、更高价值的事情上。
任何时间、任何地点生成可部署的软件
持续集成可以让您在任何时间发布可以部署的
软件。从外界来看，这是持续集成最明显的好处，我们可以对改进
软件品质和减少风险说起来滔滔不绝，但对于客户来说，可以部署的软件产品是最实际的资产。利用持续集成，您可以经常对
源代码进行一些小改动，并将这些改动和其他的代码进行集成。如果出现问题，项目成员马上就会被通知到，问题会第一时间被修复。不采用持续集成的情况下，这些问题有可能到交付前的
集成测试的时候才发现，有可能会导致延迟发布产品，而在急于修复这些缺陷的时候又有可能引入新的缺陷，最终可能导致项目失败。
增强项目的可见性
持续集成让我们能够注意到趋势并进行有效的决策。如果没有真实或最新的数据提供支持，项目就会遇到麻烦，每个人都会提出他最好的猜测。通常，项目成员通过手工收集这些信息，增加了负担，也很耗时。持续集成可以带来两点积极效果：
(1)有效决策：持续集成系统为项目构建状态和品质指标提供了及时的信息，有些持续集成系统可以报告功能完成度和
缺陷率。
(2)注意到趋势：由于经常集成，我们可以看到一些趋势，如构建成功或失败、总体品质以及其它的项目信息。
建立团队对开发产品的信心
持续集成可以建立开发团队对开发产品的信心，因为他们清楚的知道每一次构建的结果，他们知道他们对
软件的改动造成了哪些影响，结果怎么样。
1.统一的代码库
2.自动构建
3.自动测试
4.每个人每天都要向代码库主干提交代码
5.每次代码递交后都会在持续集成服务器上触发一次构建
6.保证快速构建
7.模拟生产环境的自动测试
9.每个人都清楚正在发生的状况
10.自动化的部署
1. 所有的开发人员需要在
本地机器上做本地构建，然后再提交的
版本控制库中，从而确保他们的变更不会导致持续集成失败。
2. 开发人员每天至少向
版本控制库中提交一次代码。
4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
5. 每次构建都要100%通过。
6. 每次构建都可以生成可发布的产品。
7. 修复失败的构建是优先级最高的事情。
以上是百度百科的定义，我个人理解是，尽量减少人工操作，让整个流程自动化，减少人工误操作带来的损失，并且可以并行构建，例如，我们可以让CI服务器，通过版本控制服务器自行下载项目的不同版本，然后自行进行编译构建，发布版本到应用服务器上，集成自动化测试脚本进行测试，设置可以利用脚本来管理我们的数据库，解放我们的测试到业务的重点上去工作，带个整个项目组等等好处，以上任何环节出错都可以发邮件通知相关人员去整改。