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

Posted 2023-02-19

【中文标题】持续集成 vs. 持续交付 vs. 持续部署

【英文标题】：Continuous Integration vs. Continuous Delivery vs. Continuous Deployment

【发布时间】：2015-04-20 21:28:04

【问题描述】：

这三个术语有什么区别？我的大学提供以下定义：

持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。

持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！

持续部署被描述为持续交付后合乎逻辑的下一步：只要产品通过 QA，就自动将产品部署到生产中！

它们还提供警告：如果您能够持续部署到测试系统，有时也会使用术语“持续部署”。

这一切都让我感到困惑。任何更详细（或附带示例）的解释表示赞赏！

【问题讨论】：

我认为某些业务领域内的业务原因可能会阻止公司采用持续部署模型。这样一来，这不是“合乎逻辑的下一步”。

@lambdarookie - 最好的解释！！！简明扼要:)

对我来说最好的参考atlassian.com/continuous-delivery/ci-vs-ci-vs-cd

【参考方案1】：

持续集成

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

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

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

所以大小很重要：

small task = continuous integration
big task   = frequent integration

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

持续交付

在持续交付中基本上有三个学校：

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

这所学校查看Addison-Wesley "Martin Fowler" signature series 并假设自 2007 年发布以来被称为“持续集成”，而 2011 年发布的版本被称为“持续交付” 它们可能是第 1+2 卷的同一概念概念，与连续的某事有关。

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

这所学校的观点是，持续交付就是能够支持敏捷运动中的原则，而不仅仅是概念性想法或意向书 但对于现实 - 在现实生活中。

在Agile Manifesto中第一次实际使用“持续交付”一词的地方采取了第一原则：

我们的首要任务是通过早期和持续交付有价值的软件来满足客户。

这所学校声称“持续交付”是一种范式，它包含了对您的 "definition of done" 实施自动验证所需的一切。

这所学校接受“持续交付”和流行词或大趋势"DevOps" 是同一枚硬币的反面，因为它们都试图接受或封装这种新的范式或方法，而不仅仅是一种技术。

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

第三派主张 Continuous Deployment 和 Continuous Delivery 可以互换使用，表示同一件事。

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

加入哪个学校

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

我个人主张理解持续交付与实施对敏捷运动所陈述的想法和概念的现实支持有关。所以我加入了这所学校，它说这个词包含了一个完整的范式——比如“DevOps”。

使用delivery作为deploy同义词的学校主要由创建部署控制台的工具供应商提倡，试图从更广泛的使用中获得一点炒作持续交付。

持续部署

对持续部署的关注主要与最终用户对软件更新的访问依赖于更新该信息的某些集中式源的领域相关，并且该集中式源并不总是易于更新，因为它是单一的或具有（太) 本质上具有高度一致性（Web、SOA、数据库等）。

对于生产没有集中信息源（设备、消费产品、客户端安装等）或集中信息源易于更新的软件（应用商店工件管理系统、开源存储库等），几乎没有关于持续部署一词的炒作。他们只是部署；这不是什么大事 - 这不是需要特别关注的痛苦。

持续部署并不是每个人都普遍感兴趣的事实，这也是一个论点，即声称“交付”和“部署”是同义词的学校完全错了。因为持续交付实际上对每个人都非常有意义 - 即使您正在设备中开发嵌入式软件或发布框架的开源插件。

贵校关于持续部署是持续交付的自然下一步的定义隐含地假设每个经过 QA 的交付都应该立即可供最终用户使用，这更接近于我的部落用来描述术语“持续发布”，而这又是另一个对每个人都没有普遍意义的概念。

发行可能是一件非常具有战略意义或政治性的事情，没有理由假设每个人都想一直这样做（除非他们是一家在线书店或流媒体服务类型的公司）。尽管如此，那些不会一直盲目地发布所有东西的公司可能有很多理由让他们想成为部署大师，所以他们也这样做持续部署。不是发布到生产环境，而是 release-candidates 到 production-like 环境。

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

持续部署只是将开发过程的结果持续转移到可以全面执行功能测试的类似生产环境的学科。

持续交付故事线

图片中的一切都栩栩如生：

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

【讨论】：

如果一个人真正了解什么是软件测试，那么持续集成/交付/部署/发布之间的所有“虚拟”差异就不再有意义了。

图片坏了，别处有吗？

是this 丢失的图像吗？我在其他地方找到了相同的文件名。

我不明白为什么这么多人投票这个答案，开头是“我同意你们大学的定义”，然后说“我相信你们的大学弄错了”。我发现这个答案虽然冗长且详尽，令人困惑和过度分析。只需查看亚马逊的定义以及 NoIce 在下面这个线程中所说的内容。另外请停止使用“理想”之类的术语来定义范例或策略，例如“理想情况下，每个开发任务应该是 1 天”，这在实践中很多次都不是这样，那有什么意义呢？让我们定义在现实生活中有效的策略和范式。

@Ovi-WanKenobi 他说他同意大学的部分他正在谈论持续集成的定义，而他说大学弄错了他所说的关于持续部署的部分，所以有一件事不'不要使另一个无效，它们不是相互排斥的。此外，Nolce 的答案相当混乱，而且答案的格式并没有吸引人们阅读它，即使它可能有很好的信息（这里的人们经常在阅读答案之前就根据其格式判断答案）。

【参考方案2】：

问题和答案都不符合我的简单思考方式。我是一名顾问，已经与许多开发团队和 DevOps 人员同步了这些定义，但我很好奇它如何与整个行业匹配：

基本上，我认为持续交付的敏捷实践是一个连续体：

不连续（一切手动）0% ----> 100% 持续交付价值（一切自动化）

实现持续交付的步骤：

零。当开发人员签入代码时，没有任何事情是自动化的……如果他们在签入之前已经编译、运行或执行了任何测试，那你就很幸运了。

持续构建：在每次签入时自动构建，这是第一步，但无法证明新代码的功能集成。

持续集成 (CI)： 至少自动构建和执行单元测试，以证明新代码与现有代码的集成，但最好是集成测试（端到端）。

持续部署 (CD)： 代码通过 CI 至少进入测试环境时的自动部署，最好是通过 CI 或通过将较低环境标记为手动测试后通过。即，在某些情况下测试可能是手动的，但升级到下一个环境是自动的。

持续交付： 自动发布系统并将其发布到生产中。这是用于生产的 CD 以及任何其他配置更改，例如 A/B 测试设置、向用户通知新功能、通知支持新版本和更改说明等。

编辑：我想指出，敏捷宣言第一原则 (http://agilemanifesto.org/principles.html) 中引用的“持续交付”概念与似乎引用的持续交付实践之间存在差异根据问题的上下文。持续交付的原则是努力减少库存浪费，如精益思想 (http://www.miconleansixsigma.com/8-wastes.html) 中所述。自 2001 年编写敏捷宣言以来，敏捷团队的持续交付 (CD) 实践已经出现了很多年。这种敏捷实践直接解决了这一原则，尽管它们是不同的东西，而且显然很容易混淆。

【讨论】：

很好的顾问回答。我和你在同一条船上，我同意应该有一个更真实的答案；而不是典型的大学或企业愿望清单答案。

【参考方案3】：

我认为亚马逊定义直截了当且易于理解。

“持续交付是一种软件开发方法，其中发布过程是自动化的。每个软件更改都会自动构建、测试并部署到生产中。在最终推动生产之前，一个人，一个自动化测试或业务规则决定何时进行最终推送。虽然每个成功的软件更改都可以通过持续交付立即发布到生产环境，但并非所有更改都需要立即发布。

持续集成是一种软件开发实践，团队成员使用版本控制系统并经常将他们的工作集成到同一位置，例如主分支。每个更改都通过测试和其他验证构建和验证，以便尽快检测任何集成错误。 与持续交付相比，持续集成侧重于自动构建和测试代码，后者将整个软件发布过程自动化到生产环境。”

请查看http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

【讨论】：

我认为这个答案必须被接受为这个问题的正确答案！

是的，这个答案最容易理解。

【参考方案4】：

Atlassian 对Continuous integration vs. continuous delivery vs. continuous deployment 做了很好的解释。

简而言之：

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

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

持续部署 - 是 持续交付，但无需人工干预（正在向客户发布）。

【参考方案5】：

持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。

或每天多次。基本上，只要完成任何给定的离散任务。例如，考虑一个开发单个业务应用程序的开发团队。在许多环境中，可能会发生以下情况：

一两个开发人员将本地更改保留几天，因为“它还没有准备好”。 一两个开发人员在源代码管理中创建分支，这样他们就可以“不受其他人更改的干扰”来处理他们的功能。

这些可能会导致问题。糟糕的代码/任务组织导致分支，分支导致合并，合并......导致痛苦。作为一种实践的持续集成通过鼓励每个人从同一个共享源中工作来解决这个问题。各个工作项目应足够离散，以便在短时间内（最多几小时）完成。

基本上，总体思路是在少量工作中集成一个小变化。集成一个大的变化是一项不成比例的大量工作。如果以恒定的小步骤完成，集成工作的总量会更小。这使开发人员可以将更多时间花在业务可见的功能上，而不是开发流程开销。

持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！

这遵循了离散的、定义明确的工作项的相同理念。如果有一个单一的主代码库，它只通过完整的、经过测试的、已知的工作特性进行小幅调整，那么该代码库总是稳定的。自动化测试是这里的关键，它能够通过按下按钮来证明稳定性。

需要完成的稳定工作越少（这也是开发过程的开销，应该被消除），代码库可以更频繁地推送到任何给定的环境。在许多公司中，部署可能是一个非常艰苦的过程。甚至是为期一周的全员操作。这是昂贵的并且没有商业价值。通过采用良好的工作项定义、有效的自动化测试和持续集成，团队可以自动将代码库交付到任何给定环境。

持续部署被描述为持续交付之后的合乎逻辑的下一步：只要产品通过 QA，就自动将产品部署到生产中！

在商业环境中你很少会看到这种情况发生，遇到这种情况会很开心。如果代码库可以自动测试并自动部署到任何给定的环境，那么，生产环境就像任何其他环境一样。因此，如果团队已经建立到这一点，那么通过始终能够将更新部署到生产环境，就有可能为业务带来巨大价值。

缺陷修复更快地发送给客户，新功能更快地进入市场，新想法以较小的增量在市场上进行测试以允许重新定位优先级等。

例如，假设一家公司对其基于软件的产品或服务的新功能有一个大创意。他们已经进行了一些研究，他们了解市场，并且他们相信这个想法将带来强劲的新收入。现在考虑提供该功能的两个选项：

在一次性分支中花费数月时间开发整个项目。花数周时间将其重新集成到主代码库中。花几天时间测试它。花一天时间部署它。只有然后开始跟踪生产系统中的实际收入。 实现功能的一小部分，一次一个。每周发布一个新的片段。每周获取更多有关实际收入的数据。

在第一种情况下，如果该功能没有达到预期的市场效果，那么 大量 资金会浪费在客户实际上并不想要的东西上。在第二种情况下，客户不想要它的事实是很早确定的，其余的工作没有优先级。

---

最终，这些“连续的事情”都是为了消除开发过程的开销。如果一家公司的收入线是一项特定的服务产品，那么理想情况下，他们的所有成本都应该用于该产品。开发流程开销（合并代码、合并后重新测试相同功能、手动部署任务等）实际上并没有对服务的价值做出贡献，因此这些概念试图从流程中消除这些成本。

【讨论】：

这个答案适用于你有十几个开发人员的情况，并且敏捷站会得到很好的实施，并且工作以小时为单位以工作块的形式传递。话虽如此，我还没有在一个工作并不总是变得更大的环境中工作，这使得定义理想化并且从未真正实现过。我真的很想知道是否有任何敏捷团队真的达到了这个阶段，而不会在站立会议上抱怨为委派任务分配的预期时间太短了。

【参考方案6】：

一张图可以代替很多词：

享受吧！ :-)

# 我已经更新了正确的图片...

【讨论】：

图片有点不对...持续交付是一种手动触发生产的方法。持续部署是一种自动触发生产的部署

@amirouche 是的，我做到了:)

好吧，我看错图片了。实际上，持续交付和持续部署之间的区别只是箭头颜色...... IMO 如果生产圈在持续交付中的矩形之外，两者之间的差异会更加明显。

这些图像中的验收测试和集成测试有什么区别？

【参考方案7】：

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

【讨论】：

几句话描述图片，欢迎

【参考方案8】：

我认为我们过度分析了这组“连续”的词组，并且可能会使其复杂化。在这种情况下，连续意味着自动化。对于“连续”附加的其他词，请使用英语作为您的翻译指南，请不要试图使事情复杂化！

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

“持续集成”是指您的新功能在与另一个实体交互时按预期进行测试和执行。显然，在集成发生之前，必须进行构建，并且还将使用彻底的测试来验证集成。因此，在“持续集成”中，人们使用自动化来为现有的功能增加价值，这种方式不会对现有功能产生负面影响，而是与其很好地集成，从而为整体增加感知价值。

就其英文定义而言，集成意味着事物和谐地运转，因此在代码对话中，我的 add 可以在整体中完美地编译、链接、测试和运行。如果最终产品失败了，你不会称它为集成的东西，对吗？！

在我们的上下文中，“持续部署”是“持续交付”的同义词，因为最终我们已经为客户提供了功能。但是，通过过度分析这一点，我可以说部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了。我们部署了代码，但由于我们没有有效地与利益相关者沟通，我们未能从业务角度交付！我们部署了部队，但我们还没有将承诺的水和食物送到附近的城镇。

如果我要加上“持续过渡”这个词，它会不会有它自己的优点？毕竟，也许它更适合描述代码在环境中的移动，因为它比部署或交付更具有“从/到”的含义，部署或交付可能只意味着一个位置，永远！如果我们不运用常识，这就是我们得到的。

总之，这是很简单的描述（做起来有点……复杂！），只要使用常识，英语就可以了。

【讨论】：

请看How to Answer。

【参考方案9】：

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

持续交付：在代码准备好交付后持续向环境交付代码。这可能是分期或生产。这个想法是将产品交付给用户群，该用户群可以是 QA 或客户进行审查和检查。

持续集成阶段的单元测试无法捕捉到所有的错误和业务逻辑，尤其是设计问题，这就是我们需要 QA 或用于测试的暂存环境的原因。

持续部署： 代码准备就绪后立即部署或发布。持续部署需要持续集成和持续交付，否则代码质量将无法在发布中得到保证。

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

【参考方案10】：

持续集成

自动化（构建签到 + 单元测试）

持续交付

持续集成 自动化（部署到测试环境 + 负载测试 + 集成测试） 手册（部署到生产）

持续部署

持续交付但自动化（部署到生产）

CI/CD 是一段旅程。不是目的地。

这些阶段是建议。您可以根据自己的情况调整阶段 业务需要。某些阶段可以针对多种类型重复 测试、安全和性能。根据复杂程度 您的项目和团队的结构，一些阶段可以是 在不同的层次上重复了几次。例如，结尾 一个团队的产品可以成为下一个项目的依赖项 团队。这意味着第一支球队的最终产品随后 在下一个团队的项目中作为工件上演。

脚注：

Practicing Continuous Integration and Continuous Delivery on AWS

【参考方案11】：

来源：https://thenucleargeeks.com/2020/01/21/continuous-integration-vs-continuous-delivery-vs-continuous-deployment/

什么是持续集成 持续集成是自动化构建和自动化测试的过程或开发实践，即开发人员需要将其代码多次提交到共享存储库中，每个集成都通过自动化构建和测试进行验证。

如果构建失败/成功，则会通知开发人员，然后他可以采取相关措施。

什么是持续交付 持续交付是我们在通过所有测试并具有将代码推送到生产但尚未部署的所有必需配置的任何时间点保持代码可部署的做法。

什么是持续部署 在 CI 的帮助下，我们为我们的应用程序创建了构建，并准备好推送到生产环境。在这一步中，我们的构建已准备就绪，我们可以使用 CD 将我们的应用程序直接部署到 QA 环境，如果一切顺利，我们可以将相同的构建部署到生产环境。

因此，基本上，持续部署比持续交付更进一步。通过这种做法，通过生产管道所有阶段的每个更改都会发布给您的客户。

持续部署是配置管理和容器化的结合。

配置管理： CM 就是维护服务器的配置，使其与应用程序的需求相兼容。

容器化：容器化是一系列费用，可在整个环境中保持一致性。

图片来源：https://www.atlassian.com/

【参考方案12】：

DevOps 是 3C 的组合 - 持续、沟通、协作，这导致了各个行业的主要关注点。

在物联网连接的设备世界中，产品所有者、网络、移动和 QA 等多个 scrum 功能以敏捷的方式在 scrum of scrum 循环中工作，以向最终客户交付产品。

持续集成：多个 scrum 功能在多个端点同时工作

持续交付：通过集成和部署，同时处理向多个客户交付产品。

持续部署：多个产品在多个平台上部署到多个客户。

观看此视频，了解 DevOps 如何实现物联网互联世界：https://youtu.be/nAfZt2t4HqA

【参考方案13】：

根据我在 Continuous Delivery & DevOps 课程中与 Alex Cowan 学到的知识，CI 和 CD 是产品管道的一部分，包括从观察到发布产品的时间。

从观察到设计的目标是获得高质量的可测试想法。这部分流程被认为是持续设计。

之后会发生什么，当我们从代码开始时，它被认为是一种持续交付能力，其目的是快速执行想法并发布给客户（你可以阅读 Jez Humble 的书@ 987654323@了解更多详情）。以下管道解释了持续集成 (CI) 和持续交付 (CD) 的哪些步骤。

持续集成，作为Mattias Petter Johansson explains，

是指软件团队习惯于每天进行多次合并，并且 他们有一个自动验证系统来检查那些 合并问题。

（您可以观看以下两个视频，了解使用 CircleCI 的更实用的概述 - Getting started with CircleCI - Continuous Integration P2 和 Running CircleCI on Pull Request）。

可以指定 CI/CD 管道如下，从新代码到发布的产品。

前三个步骤与测试有关，扩展了正在测试的范围。

Continuous Deployment，另一方面，是自动处理Deployment。因此，任何通过自动化测试阶段的代码提交都会自动发布到生产环境中。

注意：这不一定是您的管道应有的样子，但它们可以作为参考。

【参考方案14】：

让我们保持简短：

CI： 一种软件开发实践，团队成员至少每天集成他们的工作。每个集成都通过自动构建（包括测试）进行验证，以尽可能快地检测错误。 光盘： CD Builds on CI，您可以在其中构建软件，以便随时将软件发布到生产环境中。