内容分布：
- 什么是持续集成 1.集成 2.持续集成3.百度定义4.个人理解
- 为什么要用持续集成
- 工具
- 如何做
- 概念扩展
1.1集成CI
集成（integration）就是一些孤立的
事物或元素通过某种方式改变原有的分散状态集中在一起，产生联系，从而构成一个
有机整体的过程。
集成，就是在一起：代码commit是集成（代码在一起），编译是集成（逻辑在一起）；
部署是集成（部署包跟环境在一起），测试是集成（功能在一起），灰度是集成（系统在一起）
不断的做集成和集成结果的修正，就是持续集成；
1.2持续集成
1.2.1百度理解
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
1.2.2个人理解
为解决程序代码提交质量低，提交内容导致原有系统的bug，按时或按需自动编译版本，自动进行自动化测试。持续集成指的是，频繁地（一天多次）将代码集成到主干
最简单的持续集成可以是一台旧电脑，每人提交完代码就到电脑那合并一下代码，然后编译，部署，跑一下测试，测试通过了就表示集成成功了。
2.1为什么要持续集成：
先说“集成”，举个栗子，系统有A、B两个模块，分别是甲、乙两个人在开发，当两人吭哧吭哧开发了1个月终于把各自的功能都完成了，这时需要把AB模块集成起来，但一集成就发现各种问题，编译报错，部署不了，测试发现bug，这些Bug不知道是A模块还是B模块的，这就是传统集成的问题。
集成包括代码的合并，编译完成，成功部署，测试通过，1个bug的修复代价随着发现的时间呈指数增长，比如bug在代码检入后就发现可能花几分钟就解决了，但等到了上测试环境或者生产环境可能要花几天甚至几个月的时间，所以越早进行集成就可以越早的发现问题。
2.2好处
浅显的好处
易于定位错误。也就是当你的持续集成失败了，说明你新加的代码或者修改的代码引起了错误，这样你很容易的就可以知道到底是谁犯了错误，可以找谁来讨论。
及早在项目里取得系统级的成果。因为代码已经被集成起来了，所以即使整个系统还不是那么可用，但至少你和你的团队都已经可以看到它已经在那了。
改善对进度的控制。这点非常明显，如果每天都在集成，当然每天都可以看到哪些功能可以使用，哪些功能还没有实现。如果你是程序员，你不用在汇报任务的时候说我完成了多少百分比而烦恼，而如果你是项目经理的话，那么你也不再烦恼程序员说完成了编码的50%到底是个什么概念。
更加充分地测试系统中的各个单元。这也是我们常讲的Daily Build与Smoke Test相结合带来的绝大好处。
能在更短的时间里建造整个系统。这点恐怕要你实施以后才能得出结论。就我们而言，持续集成并没有为每个项目都缩短时间，但却比没有实施时，项目更加可控，也更加有保证。
更深刻的好处
随着时间的推移，持续集成带来的更多好处，也逐渐被认识到了，比如说：
有助于项目的开发数据的收集。比如说，项目代码量的变化，经常出错的Tests，经常出错的sourcecode，等等。
与其它工具结合的持续代码质量改进。如与CheckStyle,PMD, FindBugs, Fxcop等等等等的结合。
与测试工具或者框架结合的持续测试。如与xUnit，SilkTest,LoadRunner等等的结合。
便于Code Review。在每个build里，我们都可以知道与前一个build之间有什么改动，然后针对这些改动，我们就可以实施CodeReview了。
便于开发流程的管理。比如说，要把一个开发的build提交给测试组作测试，测完满意了，再提交到发布组去发布。
怎么做持续集成
持续集成有很多很多的好处。可是持续集成要做好的话，本身就有很多的讲究。从持续集成工具的选择到持续集成具体实施，每一点都可能影响到你使用持续集成的效果。持续集成不是持续编译，也不是仅仅用来发发邮件的工具而已。
工具
讲了这么多概念，有没一种工具把这种实践实现呢？当然有，常见的持续集成工具如下：
jenkins
travis
gitlab
buddybuild
仅列举了一些典型的，Jenkins是传统型的工具，前身是 Hudson，04 年到现在已经有十多年的历史，后几个是最近几年出现的新一批，多少都和容器技术有点关系，这里我们主要介绍Jenkins，因为这个工具比较常用，各种开发实践都可以通过大量的插件来组合实现，可定制性好很多。
jenkins
jenkins是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。— 维基百科
Jenkins 有哪些功能呢？
1.定时拉取代码并编译
2.静态代码分析
3.定时打包发布测试版
4.自定义额外的操作，如跑单元测试等
5.出错提醒
基本上都是持续集成实践中的要求和周边的一些实现措施，如提醒功能等，出错后及时提醒开发者修复，Jenkins中通过配置 SMTP 配置信息（这个一般的邮件服务提供商都有提供），邮件模板等，创建事件触发器，在事件（如编译失败）发生时，及时发送邮件通知开发者，挺方便的。
Jenkins有很多种触发构建的方式，如 webhook，定时更新代码等，同时可以在触发构建后执行自定义的构建操作，通过编辑自定义的构建脚本，几乎可以进行任何构建操作。
怎么做
基本要求：要将这种实践付诸实际，需要一些必要的条件，如下
1.一个自动构建过程，包括自动编译、分发、部署和测试等
2.一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。
3.一个持续集成服务器。
自动化构建成过程，可帮助我们节省大量时间，完成这个过程的自动化后，在以后的开发过程中，我们需要做的，就是只是提交代码到版本库中，构建自动完成，基本不再需要人工干预。
代码仓库作为构建的素材库，构建所需的代码从代码库中获得。
最好有一台服务器单独作为持续集成服务器，一方面保证了环境的纯净，一方面不影响开发，而且持续集成服务器一般是随时准备开始构建的，所以一般也不关机。
1.开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地；
2.需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次；
3.必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。
4.不更新构建失败的代码
开发人员及时的提交代码进行构建是符合上述实践的，及时拉取代码可以防止工作中的分支偏离主干分支太多。定时触发构建或者通过检测代码的修改情况在触发构建都是可以的，主要是根及时的构建新的代码。如果构建失败，则必要及时处理导致失败的问题，修复后重新构建。当然构建失败的代码就不要拉到本地了，会污染一个本来是可以运行的工作区。
