持续集成是数据支撑今年重点实施项目，上半年支持数据平台所有持续集成平台搭建工作，涉及到的语言多，构建工具繁杂，相应地也尝试了很多覆盖率工具。

　　一、那么什么是持续集成？

　　下面就谈谈我对持续集成的理解。

　　首先试想一下，在软件开发工程中，开发人员专注于编写程序逻辑代码和单元测试脚本，测试人员专注于编写测试脚本。一旦开发或者测试check in代码以后，经过几分钟就可以收到相应的测试报告，报告会告诉你，你刚编写的代码是否存在BUG，代码是否测试充分，代码是否安全，是否满足性能要求等等，这该是一件多么美妙的事情啊！

　　敏捷大师Martin Fowler给出的定义是这样的：

　　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.

　　我们来看一下这里面的几个关键词：

　　Continuous Integration isa software development practicewhere members of a teamintegrate their work frequently， usually each person integrates at least daily - leading to multiple integrations per day. Each integration isverifiedby an automated build (including test) to detect integration errors as quickly as possible.

　　从这段话中我们总结出持续集成的特点：

　　1、频繁集成

　　2、构建任务调度

　　3、自动构建测试

　　4、结果反馈

　　因此，持续集成就是由频繁集成，自动构建任务调度，自动测试和结果反馈这四个步骤构成的。

　　二、那么为什么我们要做持续集成，其优势又在哪？

　　优势一：缩短项目开发周期，减低项目风险

　　模块的集成存在难度和需要时间，很难预测集成到底要花多少时间，更糟的是，你很难了解集成的进展情况。持续集成让你任何时候你都知道自己所处的情况，软件的哪些地方在工作，哪些没有。

　　优势二：快速消除BUG

　　Bug，恶心的玩意儿，伤害我们的自信，搅乱我们的日程，还破坏我们的名声。如果在生产环境中遇到了bug，那等待你的将是故障。持续集成并不能消除bug，却能帮你快速的发现bug并予以清除。当遇到bug时，一方面，由于你只做了很小的修改，另一方面，由于是你刚写的代码，因此也使查找bug更加容易。Bug也存在积累性，bug越多，越难清除。部分原因在于bug之间存在牵连。另外也存在心理因素，bug一多，人便没那么多精力去修了——这就是所谓的“Broken Windows 综合征”。写出好多测试用例并不难。然而，要达到低bug率的程度依然是需要时间的，你还得不断地引入并改进自己的测试。