持续集成、持续交付、 持续部署之间的区别于联系

持续集成（Continuous integration， 简称CI），

持续集成是一种软件开发实践， 即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就是意味着每天可能发生多次集成，每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽早地发现集成错误。

好处

1， 快速发现错误。每完成一点更新，就集成到主干、可以快速发现错误，定位错误也比较容易。
2， 防止大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成难度变大，甚至难以集成。

Martin Fowler说过“持续集成并不能消除Bug，而是让他们非常容易发现和改正。”

持续交付 （Continuous delivery）

持续交付值得是频繁地将软件的新版本交付给质量团队或者用户，以供评审。如果评审过了，代码就是进入生产阶段。

持续交付可以看做是持续集成的下一步，它强调的是，不管怎么更新，软件是随时随地可以交付的。

持续部署（Contiuous deployment）

持续部署是持续交付的下一步，指的是通过评审以后，自动部署到生产环境。

持续部署的目标是，代码在任何时刻都是可以部署的，可以进入生产阶段。

持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别就是在最后一步，一个是“手动”部署到生产环境，一个是自动部署到生产环境。

持续交付vs持续部署

持续集成 vs 持续交付vs持续部署

基本流程

第一步，提交
开发者向代码库提交diam，或者是代码合并到主干分支（取决团队规定的开发流程，有的是本地运行单元测试过了就可以合并到主分支， 有的团队是先提交自己的分支，然后构建personal build，通过测试后再合并到主干分支）

第二步，测试
代码库对commit设置钩子hook，提交代码或者合并到主干，自动触发测试。

测试分为好几种：
单元测试：这对函数或者模块的测试
集成测试：针对整体产品的某个功能测试，又称功能测试。
端对端测试：从用户界面到数据库的全链路测试。

第三步，构建
通过测试后，代码可以合并到主干，就可以开始构建了，所谓构建就是讲源代码转换为可裕兴的实际代码，比如安装依赖，配置各种资源（css js 图片，初始数据）等等

第四部，测试（端对端测试）
构建完成后，需要进行全面的测试，需要自动化测试，

第五步，部署

通过第四步的测试后，代码就是一个可以部署的构件（artifact）了。可以将这个版本打包存档。 也可以调用Ansible Chef等
进行部署。

第六步，回滚（如果需要的话）
一旦当前版本发生问题，就要回滚到上一个构建的版本，

个人总结：
持续交付所有团队都适用，但是持续部署不一定。 持续交付打包了完整的可运行的产品，但是有些产品不适合自动部署（比如有的产品部署频率不高，或者环境复杂，或者产品的架构导致很难自动部署，例如有很多agent，如果agent不能自动升级，就需要在所有agent机器上安装对应Ansible等工具实现部署，考虑到操作系统差异，数据库差异，有些工作可能性价比不是很高）

参考：
1， https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff