持续集成、持续交付和持续部署之间的区别

持续集成:不断地将开发工作与主要分支合并，以便尽可能频繁地测试代码，以便及早发现问题。

持续交付:一旦代码准备好交付，就持续地向环境交付代码。这可以是分期或生产。其理念是将产品交付给用户群，用户群可以是QA或客户，以便进行审查和检查。

持续集成阶段的单元测试不能捕捉到所有的错误和业务逻辑，特别是设计问题，这就是为什么我们需要QA或测试环境。

持续部署:在代码准备好后立即部署或发布。持续部署需要持续集成和持续交付，否则在发布版中代码质量将得不到保证。

持续部署~~持续集成+持续交付

持续集成

我同意贵校的定义。持续集成是开发人员如何持续地将代码集成到主线的一种策略，而不是频繁地集成。

您可能会声称它只是版本控制系统中的分支策略。

这与你分配给开发者的任务大小有关;如果一项任务估计需要4-5个工作日，那么开发人员将没有动力在接下来的4-5天内交付任何东西，因为他还没有完成任何事情。

所以大小很重要:

small task = continuous integration
big task   = frequent integration

理想的任务规模不超过一天的工作量。这样，开发人员每天至少会进行一次集成。

持续交付

在持续交付中，基本上有三种学校:

持续交付是持续集成的自然延伸

这一学派，着眼于Addison-Wesley“Martin Fowler”签名系列，并做出假设，因为2007年的版本被称为“持续集成”，2011年的版本被称为“持续交付”，它们可能是与连续事物有关的同一概念思想的第1+2卷。

持续交付与敏捷软件开发有关

这所学校的观点是，持续交付是关于能够支持敏捷运动中的原则，而不仅仅是一个概念上的想法或意意书，而是真实的——在现实生活中。

在敏捷宣言的第一个原则中，第一次使用了“持续交付”这个术语:

我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。

这所学校声称“持续交付”是一个范例，它包含了实现“完成定义”的自动化验证所需的一切。

这所学校认为，“持续交付”和流行词或大趋势“DevOps”是同一枚硬币的两面，从某种意义上说，它们都试图拥抱或封装这种新的范式或方法，而不仅仅是一种技术。

持续交付是持续部署的同义词

第三种学派主张，持续部署和持续交付可以互换使用来表示同一件事。

当某些东西在开发人员手中准备就绪时，它会立即交付给最终用户，这在大多数情况下意味着应该将其部署到生产环境中。因此，“部署”和“交付”意思相同。

加入哪所学校

你的大学显然加入了第一所学校，并声称我们指的是同一出版系列的第1+2卷。我认为这是对“持续交付”一词的误用。

我个人主张这样一种理解，即持续交付与实现对敏捷运动所陈述的思想和概念的现实支持有关。所以我加入了一所学校，他们认为这个术语包含了一个完整的范式——比如“DevOps”。

使用交付作为部署的同义词的学派主要是由创建部署控制台的工具供应商倡导的，他们试图从术语持续交付的更广泛使用中获得一些宣传。

持续部署

对持续部署的关注主要与以下领域相关:终端用户对软件更新的访问依赖于某些集中式数据源的更新，而这些集中式数据源并不总是容易更新，因为它是单一的，或者本质上具有(太高)一致性(web、SOA、数据库等)。

对于许多没有集中式信息源(设备、消费产品、客户端安装等)或集中式信息源易于更新的软件领域(应用商店工件管理系统、开源存储库等)，几乎没有人大肆宣传持续部署这个术语。他们只是部署;这不是什么大不了的事，也不是什么需要特别关注的痛苦。

事实上，持续部署并不是每个人都感兴趣的事情，这也证明了那些声称“交付”和“部署”是同义词的学校完全错了。因为持续交付实际上对每个人都有很好的意义——即使你是在设备中做嵌入式软件或为框架发布开源插件。

你们大学对持续部署的定义是持续交付的自然下一步，隐含地假设每个经过QA的交付都应该立即提供给最终用户，这更接近于我的部落用来描述术语“持续发布”的定义，而“持续发布”反过来也是一个对每个人都没有意义的概念。

发布可能是一件非常具有战略意义或政治性的事情，没有理由假设每个人都想一直这样做(除非他们是在线书店或流媒体服务类型的公司)。然而，那些不盲目地一直发布所有内容的公司可能有很多理由想要成为部署大师，所以他们也会进行持续部署。不是发布到生产环境，而是发布候选环境到类似生产环境。

我再次相信你们的大学搞错了。他们把“持续部署”误认为“持续发布”。

持续部署就是持续地将开发过程的结果转移到类似生产环境的规程，在这种环境中可以全面执行功能测试。

持续交付故事线

在这幅画中，一切都活了起来:

持续集成过程是状态转换图中的前两个操作。如果成功，将启动实现done定义的持续交付管道。部署只是这个管道中必须持续执行的众多操作之一。理想情况下，从开发人员向VCS提交到管道确认我们有一个有效的候选版本，这个过程是自动化的。

我认为我们过度分析了“连续”一组词，可能把它复杂化了一点。在这种情况下，连续意味着自动化。对于“continuous”后面附加的其他单词，请使用英语作为翻译指南，不要试图把事情复杂化!

在“持续构建”中，我们自动构建(写入/编译/链接/等)我们的应用程序为特定平台/容器/运行时/等可执行的内容。

"Continuous integration" means that your new functionality tests and performs as intended when interacting with another entity. Obviously, before integration takes place, the build must happen and thorough testing would also be used to validate the integration. So, in "continuous integration" one uses automation to add value to an existing bucket of functionality in a way that doesn't negatively disrupt the existing functionality but rather integrates nicely with it, adding a perceived value to the whole.

从简单的英语定义来看，集成意味着事物和谐地运行，在代码对话中，我的add在整体中编译、链接、测试和运行完美无缺。如果一个东西不能得到最终产品你就不能称之为集成，对吧!

In our context "Continuous deployment" is synonymous with "continuos delivery" since at the end of the day we've provided functionality to our customers. However, by overanalyzing this, I could argue that deploy is a subset of delivery because deploying something doesn't necessarily mean that we delivered. We deployed the code but because we haven't effectively communicated to our stakeholders, we failed to deliver from a business perspective! We deployed the troops but we haven't delivered the promised water and food to the nearby town.

如果我加上“连续过渡”一词，它会有自己的优点吗?毕竟，也许它更适合描述代码在环境中的移动，因为它具有“从/到”的内涵，而不是部署或交付，后者可能只意味着永久地在一个位置!如果我们不运用常识，这就是我们得到的结果。

总之，这是很简单的描述(做起来有点…复杂!)，只要使用常识，英语，你就会好起来的。

Atlassian发布了一个关于持续集成、持续交付和持续部署的很好的解释。

简而言之:

持续集成——是 每当新提交被推入分支时，自动构建和测试应用程序。

持续交付——即持续集成+通过“点击一个按钮”将应用程序部署到生产环境(通常是发布给客户，但按需发布)。

持续部署-是 持续交付，但没有人为干预(向客户发布正在进行中)。

持续集成、持续交付和持续部署之间的区别