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

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

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

连续交付被描述为连续交付后的逻辑下一步：只要产品通过质量检查，就自动将其部署到生产中！

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

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

持续集成

我同意你大学的定义。持续集成是开发人员如何将代码连续（而不是频繁）集成到主线的一种策略。

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

它与您分配给开发人员的任务大小有关；如果估计一项任务需要4-5个工日，那么开发人员将没有任何动机在接下来的4-5天之内交付任何东西，因为他还没有做任何事情-到目前为止。

因此大小很重要：

small task = continuous integration
big task   = frequent integration

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

持续交付

连续交付中基本上有三所学校：

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

这所学校着眼于Addison-Wesley的“ Martin Fowler”签名系列，并假设自2007年发行以来被称为“ Continuous Integration”，而其后于2011年发行的被称为“ Continuous Delivery”，它们的数量可能是1 + 2与连续事物有关的同一概念的观点。

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

这所学校偏离了以下观点：“持续交付”就是要能够支持敏捷运动中的原则，这不仅是概念上的想法或意向书，而且是现实生活中的现实。

沿用《敏捷宣言》中的第一条原则，其中首次实际使用了“连续交付”一词：

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

这所学校声称“连续交付”是一个范式，它包含了对“完成的定义”进行自动验证所需的一切。

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

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

第三所学校主张“ 持续部署”和“ 持续交付”可以互换使用，意思是同一件事。

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

加入哪所学校

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

我本人主张理解“ 持续交付”与为敏捷运动提出的思想和概念提供现实支持有关。因此，我加入了这所学校的行列，该术语涵盖了整个范式-例如“ DevOps”。

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

持续部署

在最终用户对软件更新的访问依赖于此信息的某些集中式源的更新且该集中式源由于其整体性或一致性太强而并不总是易于更新的领域中，对持续部署的关注最为相关。本质上（网络，SOA，数据库等）。

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

持续部署并不是每个人都普遍感兴趣的事实，这也证明了认为“交付”和“部署”是同义词的学校的理解是错误的。因为“连续交付”实际上对每个人都非常有意义-即使您正在设备中进行嵌入式软件开发或为框架发布开源插件也是如此。

您大学对“持续部署是持续交付的自然下一步”的定义隐含地假设，经过质量检查的每个交付都应立即提供给最终用户，这更接近于我的部落用来描述“持续交付”的定义。释放”，这又是另一个对所有人也没有意义的概念。

发布可能是一项具有战略意义或政治意义的事情，没有理由假设每个人都希望一直这样做（除非他们是一家在线书店，是一家流媒体服务公司）。但是，不会一直盲目发布所有内容的公司可能出于多种原因而仍然希望成为部署大师，因此他们也进行了持续部署。不是发布到生产环境，而是发布到类似生产环境的候选版本。

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

连续部署只是不断地将开发过程的结果转移到可以全面执行功能测试的生产环境中的原则。

持续交付故事情节

在图片中，一切都变得生动起来：

持续集成过程是状态转换图中的前两个动作。如果成功，这将启动实现完成的定义的持续交付管道。部署只是在此管道中必须连续执行的许多操作之一。理想情况下，该过程是自动的，从开发人员致力于VCS到管道确认我们拥有有效的发布候选者。

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

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

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

持续交付的步骤：

零。当开发人员检入代码时，没有任何东西是自动的。如果他们在检入之前已经编译，运行或进行了任何测试，您将很幸运。

1. 连续构建：第一步是在每次签入时自动构建，但这并不能证明新代码的功能集成。

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

3. 连续部署（CD）：当代码至少将CI通过测试环境时自动进行部署，当通过CI或通过在手动测试后将较低环境标记为“通过”证明质量时，最好将其部署到较高环境中。IE，测试在某些情况下可能是手动的，但升级到下一个环境是自动的。

4. 持续交付：自动发布并将系统发布到生产中。这是CD投入生产，加上其他配置更改（例如A / B测试设置，向用户通知新功能，通知支持新版本和更改说明等）。

编辑：我想指出，敏捷宣言的第一条原则（http://agilemanifesto.org/principles.html）中提到的“连续交付”的概念与持续交付的做法之间存在差异，正如问题上下文所提及的那样。如精益思想（http://www.miconleansixsigma.com/8-wastes.html）中所述，持续交付的原则是努力减少库存浪费。自从2001年编写《敏捷宣言》以来，敏捷团队就不断采用了持续交付（CD）的做法。这种敏捷实践直接解决了该原则，尽管它们是不同的东西，而且很容易混淆。

我认为亚马逊的定义是直接且易于理解的。

“ 持续交付是一种软件开发方法，其中发布过程是自动进行的。每个软件更改都将自动构建，测试并部署到生产中。在最终投入生产之前，人员，自动化测试或业务规则将决定何时发布产品。尽管每项成功的软件更改都可以立即发布并持续交付，但最终的推动应该发生，但并非所有更改都需要立即发布。

持续集成是一种软件开发实践，团队成员使用版本控制系统并将其工作频繁地集成到同一位置（例如主分支）。每次更改都会通过测试和其他验证进行构建和验证，以便尽快检测到任何集成错误。与持续交付相比，持续集成的重点是自动构建和测试代码，从而使整个软件发布过程自动化直至生产。”

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

Atlassian发布了有关持续集成与持续交付与持续部署的很好的解释。

简而言之：

持续集成 -每当将新提交提交到分支中时，它都是一种自动构建和测试应用程序的自动化方法。

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

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

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

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

• 一到两个开发人员将本地更改保留几天，因为“尚未准备好”。
• 一两个开发人员在源代码管理中创建分支，以便他们可以“不受其他人的更改所困扰”地使用其功能。

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

基本上，总的想法是将少量更改整合到少量工作中。整合大的变更是一项不成比例的大量工作。如果以恒定的小步骤完成，则集成工作的总规模较小。这使开发人员可以将更多的时间花费在业务可见的功能上，而不是花费开发过程的开销。

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

这遵循离散的，定义明确的工作项的相同思想。如果只有一个主代码库，并且仅通过完整的，经过测试的已知工作功能以很小的增量进行调整，则该代码库将始终保持稳定。在这里，自动化测试是关键，它可以证明您只要按一下按钮就可以确保稳定性。

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

连续交付被描述为连续交付后的逻辑下一步：只要产品通过质量检查，就自动将其部署到生产中！

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

缺陷修复程序可以更快地发送给客户，新功能可以更快地进入市场，新思想可以以较小的增量针对市场进行测试，从而可以重定向优先级等。

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

1. 花一个月的时间在一个分支中开发整个事情。花数周时间将其集成回主代码库。花几天的时间进行测试。花一天时间部署它。只有这样开始在生产系统中跟踪的实际收入。
2. 一次实现一小部分功能。每周发布新的版本。每周可获得更多有关实际收入的数据。

在第一种情况下，如果该功能没有理想的市场效果，那么大量金钱浪费在客户实际上不想要的东西上。在第二种情况下，客户不希望这样做的事实被确定的时间要早​​得多，而其余工作的优先级则降低了。

最终，这些“连续的事情”都与消除开发过程的开销有关。如果公司的收入线是特定的服务产品，那么理想情况下，所有费用都应计入该产品。开发过程的开销（合并代码，合并后重新测试相同的功能，手动部署任务等）实际上并没有增加服务的价值，因此这些概念试图从过程中消除这些成本。

一个图形可以替换许多单词：

请享用！:-)

＃我已更新正确的图像...

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

我认为我们已经过分分析，可能会使“连续的”单词组有些复杂。在这种情况下，连续意味着自动化。对于“ continuous”后面的其他单词，请使用英语作为翻译指南，请不要尝试使事情复杂化！在“连续构建”中，我们自动将应用程序构建（写入/编译/链接/等）到对于特定平台/容器/运行时/等可执行的文件中。“持续集成”是指您的新功能在与另一个实体进行交互时会按预期进行测试和执行。显然，在进行集成之前，必须进行构建，并且还将使用全面的测试来验证集成。因此，在“持续集成”中 一个人使用自动化以一种不会给现有功能带来负面影响的方式来增加其价值，而不会破坏现有功能，而是与其进行很好的集成，从而为整体增加可感知的价值。集成仅凭英文定义就意味着事物和谐地和谐相处，因此在代码对话中，我添加了所有的编译，链接，测试并在整体上完美运行。如果最终产品不合格，您将不会称其为集成产品，对吗？在我们的上下文中，“持续部署”是“持续交付”的同义词，因为我们最终已经为客户提供了功能。但是，通过过度分析，我可以认为部署是交付的子集，因为部署某些内容并不一定意味着我们已经交付了。我们部署了代码，但是因为我们没有 无法有效地与利益相关者沟通，我们无法从业务角度进行交付！我们部署了部队，但尚未向附近城镇运送承诺的水和食物。如果我加上“连续过渡”一词怎么办，它会有自己的优点吗？毕竟，也许它更适合描述代码在环境中的移动，因为它比起可能只在一个位置永久存在的部署或交付具有更多的“从/到”的含义！如果不运用常识，这就是我们得到的。它有自己的优点吗？毕竟，也许它更适合描述代码在环境中的移动，因为它比起可能只在一个位置永久存在的部署或交付具有更多的“从/到”的含义！如果不运用常识，这就是我们得到的。它有自己的优点吗？毕竟，也许它更适合描述代码在环境中的移动，因为它比起可能只在一个位置永久存在的部署或交付具有更多的“从/到”的含义！如果不运用常识，这就是我们得到的。

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

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

持续交付：一旦准备好交付代码，就将代码连续交付给环境。这可能是分期或生产。想法是将产品交付给用户群，可以是质量检查人员或客户进行审查和检查。

在持续集成阶段中的单元测试无法捕获所有错误和业务逻辑，尤其是设计问题，这就是我们需要QA或登台环境进行测试的原因。

持续部署：准备就绪后立即部署或发布代码。持续部署要求持续集成和持续交付，否则发行版中不能保证代码质量。

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

持续集成

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

持续交付

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

持续部署

• 连续交付但自动化（部署到生产中）

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

这些阶段是建议。您可以根据业务需要调整阶段。对于多种类型的测试，安全性和性能，可以重复某些阶段。根据项目的复杂性和团队的结构，某些阶段可以在不同级别重复几次。例如，一个团队的最终产品可能成为下一个团队项目中的依赖项。这意味着，第一小组的最终产品随后将作为下一个小组项目中的工件上演。

脚注：

在AWS上进行持续集成和持续交付

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

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

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

什么是持续交付 持续交付是一种做法，我们在任何时候都通过所有测试，并具有将代码推入生产环境但尚未部署的所有必需配置，以使我们的代码可部署。

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

因此，基本上，持续部署比持续交付要迈出一步。通过这种做法，通过生产流程各个阶段的每项更改都会发布给客户。

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

配置管理： CM与维护服务器的配置有关，这些配置将与应用程序需求兼容。

集装箱化：集装箱化是一组通行费，将在整个环境中保持一致性。

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

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

在物联网连接的设备世界中，产品所有者，Web，移动和质量保证等多个Scrum功能以敏捷的方式在Scrum周期的Scrum周期中工作，以将产品交付给最终客户。

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

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

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

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

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

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

之后，当我们从《守则》开始时，会发生什么事情，它被认为是一种持续交付功能，其目的是快速执行想法并快速发布给客户（您可以阅读Jez Humble的书《持续交付：通过构建，测试，和部署自动化以获取更多详细信息）。以下管道说明了持续集成（CI）和持续交付（CD）包括哪些步骤。

正如Mattias Petter Johansson解释的那样，持续集成

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

（您可以使用CircleCI观看以下两个视频，以获得更实际的概述-CircleCI 入门-持续集成P2和在Pull Request上运行CircleCI）。

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

前三个步骤与测试有关，扩展了被测试对象的范围。

另一方面，持续部署是自动处理部署。因此，任何通过自动化测试阶段的代码提交都会自动发布到产品中。

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