s
持续集成,持续交付,持续部署之间的区别
https://www.cnblogs.com/zhuwenlubin/p/5888498.html
持续交付
https://blog.csdn.net/haoxin963/article/details/81779929
随着微服务架构与容器虚拟化技术的发展，持续集成与持续交付的概念又重新回到了大家的视野，越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题；使用持续交付的工具来实现代码在不同环境上的自动部署。
持续交付的概念和产生
传统软件的开发与交付的周期都很漫长，一款普通的企业软件通常需要十几个开发人员，几个月的时间来完成，从需求的分析、系统的设计、编写测试用例、系统开发、单元测试、组装测试到交付调试。有条不紊的流程与规范像一辆绿皮火车下的枕木，稳定而可靠的保证整个系统缓慢的推进，每一次交付、升级，都需要提供基础的硬件、软件的环境、软件的代码、软件的文档与手册。
还记得刚刚迈入软件开发行业的时候，跟随公司的服务团队，驻场交付产品，每一个驻场工程师都按照之前预演过好多遍的流程，对照着系统的部署手册，一步一步的组装硬件，安装软件，稍有差池，就要按照对应的应急预案进行回滚。开始的时候觉得交付像一个神圣的仪式，将用智慧和汗水构建成的软件交付给客户使用，是一种非常荣耀和值得骄傲的事情；后来越来越多次的产品交付让我深深的感觉每一次交付都像分娩一样痛苦，扪心自问是否有简单更舒畅的流程可以将软件交付给客户呢？
要想快速的交付，首先要明白软件交付过程中遇到的核心问题是什么。总结成两个词“自动”与“可靠”。自动是一个很宽泛的词汇，在软件交付中代表着测试自动化、交付自动化、运维自动化等等，而可靠讲的是每一次交付要保证是当前的交付是稳定的或可回滚到稳定版本的。为了解决“自动”与“可靠”的问题，敏捷开发鼻祖Martin Fowler提出了持续集成与持续交付的概念，它所描述的软件开发，是从原始需求识别到最终产品部署到生产环境这个过程中，需求以小批量形式在团队的各个角色间顺畅流动，能够以较短地周期完成需求的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈，并且在这个过程中，需求分析、产品的用户体验和交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。通过这种小步快跑的方式，将小功能快速迭代、验证、交付，通过自动化的工具，将测试、部署、运维自动化，减少需求在软件生命周期中流动的时间。
持续交付工具链
但是前辈只给了我们先进的思想，并没有给出默认的实现。不同的公司、不同的产品、不同的技术栈、不同的开发与部署形态决定了持续集成与持续交付注定是因人而异的，大家不断摸索什么样的方式是持续集成与持续交付的最佳实践。归根结底，持续集成与持续交付的难点在于如何屏蔽不同语言、不同框架、不同系统之间的持续集成与持续交付流程的差异性。曾经幻想过是否能有一种方式可以归约软件的交付，而这就是Martin Fowler留给我们的课后思考题-论如何实现持续集成与持续交付的流程标准化。
当你问十个哲学家什么是哲学的时候，你会得到十一种答案，因为每个人都有对哲学不同的理解，对于持续交付也一样。个人选取了目前开源社区中最流行和优秀的开源软件，经过改造后搭建了全开源端到端交付流水线，这应该也是目前各大互联网公司使用最广泛的方案。其中Jenkins作为业内优秀的的CI/CD工具，担任整套了工具链的核心组织工作。
持续交付 VS Devops
Devops定义：
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps的出现有其必然性。在软件开发生命周期中，遇到了两次瓶颈。第一次瓶颈是在需求阶段和开发阶段之间，针对不断变化的需求，对软件开发者提出了高要求，后来出现了敏捷方法论，强调适应需求、快速迭代、持续交付。第二个瓶颈是在开发阶段和构建部署阶段之间，大量完成的开发任务可能阻塞在部署阶段，影响交付，于是有了DevOps。
Devops三大原则：
1、基础设施即代码（Infrastructure as Code）
DeveOps的基础是将重复的事情使用自动化脚本或软件来实现，例如Docker（容器化）、Jenkins（持续集成）、Puppet（基础架构构建）、Vagrant（虚拟化平台）等
2、持续交付（Continuous Delivery）
持续交付是在生产环境发布可靠的软件并交付给用户使用。而持续部署则不一定交付给用户使用。涉及到2个时间，TTR（Time to Repair）修复时间，TTM（Time To Marketing）产品上线时间。要做到高效交付可靠的软件，需要尽可能的减少这2个时间。部署可以有多种方式，比如蓝绿部署、金丝雀部署等。
3、协同工作（Culture of Collaboration）
开发者和运维人员必须定期进行密切的合作。开发应该把运维角色理解成软件的另一个用户群体。协作有几个的建议：1、自动化（减少不必要的协作）；2、小范围（每次修改的内容不宜过多，减少发布的风险）；3、统一信息集散地（如wiki，让双方能够共享信息）；4、标准化协作工具（比如jenkins）
持续交付和Devops的关系
devops（开发到运维）是另外一个现在很火的工程概念，和持续交付的关系很多时候让人傻傻分不清楚。从概念上来说，DevOps更关注Ops(Operations), 持续交付更关注Dev (Development) 。他们的目标都是解决相同的问题，即加速软件开发，减少软件开发到交付或上线的时间，并使开发、测试、运维几个角色协作的更紧密。一般来说个人倾向于两者说的是同一回事，它们只不过是一枚硬币的正反面而已，在概念上并没有什么争议。
引用《持续交付》译者乔梁的观点，细微的差别可能就是持续交付体现的是产品交付的完整过程，devops强调的是从开发到运维的交付，传统的持续集成则更强调产品研发过程（开发+测试）。
end