持续集成（Continuous integration，简称CI）
持续集成是什么？
CI，是指在一段时间内（如：约定好的一天内或是一个上午），多次的将代码提交到主干上去。自然，每次都要通过测试。
大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
为什么要使用持续集成？
-
减少风险
可以快速的发现错误 -
可快速定位错误
-
可降低代码整合的错误
-
防止长时间过后，集成失败
-
可以更好的了解进度，更好的收集数据
emmm~~博主表示很难受，在之前的开发之中，打算将所有功能完善之后才去Pull代码、Commit代码以及Push的时候，突然发现。。。。悲剧了
代码拉下来冲突一堆
为了时间问题，当时就是直接重新拉取代码，再去移动新功能代码
继续拿，大师Martin Fowler的话来讲就是，持续集成并不解决BUG，而是能够更加快速的发现以及更正。
自然地，当我们持续集成的时候，必须也要保证代码的可行性，简单讲就是单元测试通过了，我们才去集成。不然就是搞事情了~~~
与持续集成相关的，一般还会搭上持续交付以及持续部署
持续交付
持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户。持续交付强调的是，无论如何更新，都可以随时随地的交付软件的。
过程简单来说就是：
当集成完成以后，可以自动的部署到测试环境当中，而后进入类生产环境中 当一切都经过持续集成后，没问题的时候，我们再手动部署到生成环境。
为什么要交给质量团队或是用户呢？
开句玩笑话的话，那就是，大部分开发人员在完成功能的时候表面看似波澜不惊，一望无垠。但是，内心却是风起云涌。
为什么? 很简单，因为是我们自己写的，所以，基本上找不出反驳自己的问题，但是就是有问题。。。。就是找不出来 尴尬
这时候，就需要专业的质量团队（测试人员）或是用户了。
因为一个是专业的嘛，另一个就是那句话了 ，群众的眼睛是雪亮雪亮的~~BinlingBinling
持续部署
- 持续部署(continuousdeployment)是持续交付的下一步，指的是代码通过评审测试以后，自动部署到生产环境。【图片的AUTO 交付是手动的】
- 持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。
- 持续部署的前提是能自动化完成测试、构建、部署等步骤。
持续集成的流程
- 提交
如，我们经常的使用开发工具将代码，提交到版本控制系统（GitHub/GitLab)当中。 版本控制系统请移步此处点击 - 测试
如，单元测试以及集成测试。 - 构建
所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。
常用的构建工具如下：
- Jenkins
- Travis
- Codeship
- Strider
-
再一次测试
此次，测试可以是说是全面性的测试，或是为了减少问题的行为。只为，此次集成的可行性。覆盖率一般大于第一次的测试。 -
部署
打包，将此次版本发布于服务器上。 -
回滚
如果出现问题，即刻，恢复到上个版本。