1、持续集成定义
记得小鱼在《测试开发之：Jenkins持续集成（上），安装与配置》说过什么是持续集成，
可能有些小伙伴觉得说的太笼统或者还是对持续集成的定义有些模糊，
所以这篇，就聊一聊持续集成
1.1 什么是持续集成
持续集成(Continuous Integration, CI)是软件工程的一个重要领域。
在现代软件开发中，多个开发者(Developer)工作在同一个共享的代码仓库(Repository)上。
每一次开发者往代码仓库主干(Master/Trunk)提交(Submit)或者合入(Merge)代码改动的过程，可以认为是一次集成。
1.2 持续集成的过程
持续集成，就是持续的代码合入过程。
每一次集成，绝非是将开发者的代码改动与主干已有代码合并这么简单，而是一个复杂的过程：通常包括代码合并，构建，静态检查，动态检查，运行，多级测试(单元测试/模块测试/集成测试)，代码评审等一系列任务的系统工程。
这些任务的侧重点各有不同，但是其目标是共同的，那就是检验开发者的代码改动是否符合质量要求，确保主干不被代码改动破坏。
如图
1.2 什么是非持续集成
如果对持续集成的定义还有些模糊，我们从它的对立面，即非持续集成来理解，似乎就更容易懂了。
它的对立面分两部分，一次性集成和非持续集成
1.2.1 一次性集成
一次性集成：
将开发和集成分离，等开发工作全部完成之后，再进行集成。
这种方案会遇到集成黑洞(Integration Hell)问题：在集成阶段，大量的软件问题集中爆发，层出不穷。
由于集成的对象包含了非常多的代码改动，并且代码改动的时间已经过去较长时间，软件问题的定位和解决将困难重重。
此时的集成，将吞噬有限的项目时间，阻止项目往前推进，成为项目交付的重大瓶颈。
1.2.2. 非持续集成
非持续集成：
集成的频率介于一次性集成和持续集成之间，表现形式有多种。
举例：
按照时间周期性地集成，每周集成一次；
或者按照特性(Feature)集成，每完成一个新特性的开发就集成一次。
这种方式能够避免产生大的集成黑洞问题，但是每一次集成仍然可能会遇到较小的集成黑洞。对于发现的软件问题，定位和解决难度仍然不小。
所以，解决黑洞的办法，就是要做到真正的持续集成。
1.3 如何做到真正的持续集成
针对上面说的，如何做到真正的持续集成，这就要从考虑这几个问题了：
为什么要集成？
集成的对象是什么？
持续集成的目的是什么？
在实际的实践过程中，我们可能会有答案，例如：
持续集成的目的就是验证代码改动是否能够合入主干；
集成的对象应当是开发者每一次的代码改动；
代码改动是事件(Event)，持续集成应该是事件触发，而不是时间触发。
基于这个初心，凡是有代码改动的时候，就应该进行集成。
从形态来说，这里的改动包含新代码增加，已有代码修改和已有代码的删除。
从目的来说，这里的改动包含新特性的实现，软件问题的修复，已有代码的重构等。
任何一行代码改动都需要经过充分验证才能被接受。
没有经过验证和集成的代码改动，不能合入主干。
主干的质量至关重要。由于每次集成均依赖于主干，一旦主干被破坏，所有其他开发者的代码改动将都无法正常提交，造成严重后果。
归根结底：
由代码提交(Commit)所触发的集成，才是真正的持续集成。
或者说，一次提交，一次集成 (One Commit，One Integration)。
这样的持续集成，其好处是多方面的。
2、持续集成优点
2.1 及早发现和解决问题
及早发现和解决软件问题：
一旦代码改动有问题，便可以通过集成来发现，并且原地和及时地反馈给开发者。
由于排查范围小，离修改时间近，定位问题将相对容易。
针对已发现的问题的修复，也能很快得到验证
2.2 降低交付风险
降低交付风险：
将漫长的集成工作分解，将未来的集成放在现在，将不可预知的集成变得可预知，避免在项目的后期因集成黑洞导致延迟交付。
同时，由于主干被严格保护，因此产品在绝大部分时候(除非主干被破坏)都处于可交付的状态。
2.3 利于项目管理
利于项目管理：
持续集成，让项目的进度更加可见。
持续集成的状态，就是项目的状态。
通过持续集成系统，可以实时准确了解开发的状态和项目的进度。
3、总结
针对今天的持续集成内容，小鱼用以下几点总结，希望能让更多的小伙伴了解持续集成：
持续集成将集成黑洞问题化整为零，各个击破。
持续集成将软件问题发现在萌芽阶段。
当然我们需要承认，持续集成本身并不能消灭任何软件问题，而是让软件问题更方便地被发现，定位和解决。
持续集成的中心任务，都是为了让这个目的变得更容易，而不是更难。
再多的理论，都不及一次实践，所以，持续集成的安装配置及构建，请看小鱼的这两篇博文：
《测试开发之：Jenkins持续集成（上），安装与配置》
《测试开发之：Jenkins持续集成(下)，构建与运行》
