文章目录
- [1 持续集成](#1 持续集成)
-
- [1.1 持续集成的好处](#1.1 持续集成的好处)
- [1.2 持续集成的目的](#1.2 持续集成的目的)
- [1.3 没有持续集成的状况](#1.3 没有持续集成的状况)
- [2 持续交付](#2 持续交付)
- [3 持续部署](#3 持续部署)
- [4 持续交付和持续部署的区别](#4 持续交付和持续部署的区别)
1 持续集成
持续集成 （Continuous integration，简称CI），简单来说持续集成就是频繁地 （一天多次）将代码集成到主干 。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。
**持续集成得过程：**先把代码放到git、Jenkins从git获取代码进行构建、测试、生成结果再返回给客户端。
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，可以确定新代码和原有代码能否正确地集成在一起。
1.1 持续集成的好处
-
提高开发人员的工作效率。持续集成可将开发人员从手动任务中解放出来，并且鼓励有助于减少发布到客户环境中的错误和缺陷数量的行为，从而提高团队的工作效率。
-
快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
-
防止分支大幅偏离主干，如果不经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
-
从检出代码、编译构建、运行测试、结果记录、测试统计等都是自动完成的，减少人工干预。
-
任何时间、任何地点生成可部署的软件，出现问题，项目成员会被马上通知到，问题第一时间修复。
-
增强项目可见性，有效的控制台日志能帮助我们更好的解决存在的问题。
简单的来说为什么需要持续集成？
过去，一个团队的开发人员可能会孤立地工作很长一段时间，只有在他们的工作完成后，才会将他们的更改合并到主分支中。这使得合并代码更改变得困难而耗时，而且还会导致错误积累很长时间而得不到纠正。这些因素导致更加难以迅速向客户交付更新。
1.2 持续集成的目的
让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
持续集成并不能消除 Bug，而是让它们非常容易的发现和改正。
1.3 没有持续集成的状况
2 持续交付
持续交付（Continuous Delivery，简称CD）指的是：频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续交付是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境。下图反应的是CI/CD 的大概工作模式。
持续交付是经典的敏捷的软件开发方法的自然延伸，它强调产品在修改后到部署上线的流程要敏捷话、自动化。甚至一些较小的改变也要尽早的部署上线。通俗的讲可以有几个特点：
- 代码越早交付出去，用户越早能用到，快就是商业价值。
- 用户反馈能及时作出处理，能帮助产品市场人员调整测策略。
- 降低修改成本。
3 持续部署
持续部署（Continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
4 持续交付和持续部署的区别
CD是持续交付和持续部署，但是持续交付不等于持续部署。持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。具体区别参考下图：
