目录

关键词

持续：不断的获取反馈，相应反馈

集成：编译、测试、打包

部署：应用组件或基本设施的代码或配置变更在产品环境生效

发布：具有业务影响的功能变化对最终用户可见

部署到发布：一般使用特性开关或灰度发布等技巧可以使我们更加频繁地部署变更到产品环境但并不发布功能。

频繁部署的好处：可以有效降低变更带来的风险，同时业务仍然可以保持向最终用户发布功能的控制，也可以高频地验证业务数据及及时反馈并调整业务

持续交付和持续部署，还仍然一直有争议，不同公司不同业务不同团队由于业务和服务对象不一样，交付和部署的过程和对象也会不一样，只要内部统一即可，灵活理解。

持续集成

集成：是指开发人员将研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题，及避免与其他协作开发人员模块冲突。传统集成是需要手动约定构建及内部测试，手动确认是否正确集成本次代码交付。

持续集成：是开发人员提交了新代码之后，立刻进行自动构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

持续交付

交付：这里我们更倾向于是开发向测试方向交付阶段性代码产品，以便进行功能、集成、系统测试

持续交付：在持续集成的基础上，将集成后的自动代码部署到更贴近真实运行环境的测试环境「类生产环境」中。比如，我们完成单元测试后，可以把代码部署到测试环境中。如果代码没有问题，可以继续手动部署到生产环境中。

持续部署

部署：将应用组件或产品代码及配置部署到生产环境，并确认达到可随时发布状态

持续部署则是在持续交付的基础上，将部署到生产环境的过程自动化。

持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题后导致返工，而持续集成、持续交付、持续部署正好可以及时发现问题并及时解决，避免在计划时间出现意外问题导致上线或发布意外搁置延期。

参考

https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

本文收藏来自互联网，仅用于学习研究，著作权归原作者所有，如有侵权请联系删除

markdown 9ong@TsingChan

部分引用格式为收藏注解，比如本句就是注解，非作者原文。