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

痛定思痛。 2024-04-18 23:00 4阅读 0赞

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

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

## 好处 ##

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

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

# 持续交付 （Continuous delivery） #

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

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

# 持续部署（Contiuous deployment） #

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

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

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

# 持续交付vs持续部署 #

![在这里插入图片描述][20190913150417539.gif]

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1c3NsZQ_size_16_color_FFFFFF_t_70]

# 基本流程 #

第一步，提交  
开发者向代码库提交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

[20190913150417539.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c17d9e3b194643bf9f76963288bbbbf3.gif
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3J1c3NsZQ_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/b06a6481fe314a30bd8f14ea58ff44e0.jpg