这三个术语有什么区别？我的大学提供以下定义：
持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。
持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！
持续部署被描述为持续交付后合乎逻辑的下一步：只要产品通过 QA，就自动将产品部署到生产中！
它们还提供警告：如果您能够持续部署到测试系统，有时也会使用术语“持续部署”。
这一切都让我感到困惑。任何更详细（或附带示例）的解释表示赞赏！
【问题讨论】：
标签： continuous-integration continuous-deployment continuous-delivery
我同意贵校的定义。 持续集成是开发人员如何将代码持续集成到主线的一种策略——而不是频繁地。
您可能会声称这只是您的版本控制系统中的一种分支策略。
这与您分配给开发人员的任务的大小有关；如果一项任务预计需要 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 到管道确认我们拥有有效的候选发布版本，整个过程都是自动化的。
【讨论】：
问题和答案都不符合我的简单思考方式。我是一名顾问，已经与许多开发团队和 DevOps 人员同步了这些定义，但我很好奇它如何与整个行业匹配：
基本上，我认为持续交付的敏捷实践是一个连续体：
不连续（一切手动）0% ----> 100% 持续交付价值（一切自动化）
实现持续交付的步骤：
零。当开发人员签入代码时，没有任何事情是自动化的……如果他们在签入之前已经编译、运行或执行了任何测试，那你就很幸运了。
持续构建：在每次签入时自动构建，这是第一步，但无法证明新代码的功能集成。
持续集成 (CI)： 至少自动构建和执行单元测试，以证明新代码与现有代码的集成，但最好是集成测试（端到端）。
持续部署 (CD)： 代码通过 CI 至少进入测试环境时的自动部署，最好是通过 CI 或通过将较低环境标记为手动测试后通过。即，在某些情况下测试可能是手动的，但升级到下一个环境是自动的。
持续交付： 自动发布系统并将其发布到生产中。这是用于生产的 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 对Continuous integration vs. continuous delivery vs. continuous deployment 做了很好的解释。
简而言之：
持续集成 - 是 每当新的提交被推送到分支时，自动构建和测试应用程序。
持续交付 - 持续集成 +通过“点击按钮”将应用程序部署到生产环境（通常是发布给客户，但按需）。
持续部署 - 是 持续交付，但无需人工干预（正在向客户发布）。
【讨论】：
持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。
或每天多次。基本上，只要完成任何给定的离散任务。例如，考虑一个开发单个业务应用程序的开发团队。在许多环境中，可能会发生以下情况：
这些可能会导致问题。糟糕的代码/任务组织导致分支，分支导致合并，合并......导致痛苦。作为一种实践的持续集成通过鼓励每个人从同一个共享源中工作来解决这个问题。各个工作项目应足够离散，以便在短时间内（最多几小时）完成。
基本上，总体思路是在少量工作中集成一个小变化。集成一个大的变化是一项不成比例的大量工作。如果以恒定的小步骤完成，集成工作的总量会更小。这使开发人员可以将更多时间花在业务可见的功能上，而不是开发流程开销。
持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！
这遵循了离散的、定义明确的工作项的相同理念。如果有一个单一的主代码库，它只通过完整的、经过测试的、已知的工作特性进行小幅调整，那么该代码库总是稳定的。自动化测试是这里的关键，它能够通过按下按钮来证明稳定性。
需要完成的稳定工作越少（这也是开发过程的开销，应该被消除），代码库可以更频繁地推送到任何给定的环境。在许多公司中，部署可能是一个非常艰苦的过程。甚至是为期一周的全员操作。这是昂贵的并且没有商业价值。通过采用良好的工作项定义、有效的自动化测试和持续集成，团队可以自动将代码库交付到任何给定环境。
持续部署被描述为持续交付之后的合乎逻辑的下一步：只要产品通过 QA，就自动将产品部署到生产中！
在商业环境中你很少会看到这种情况发生，遇到这种情况会很开心。如果代码库可以自动测试并自动部署到任何给定的环境，那么，生产环境就像任何其他环境一样。因此，如果团队已经建立到这一点，那么通过始终能够将更新部署到生产环境，就有可能为业务带来巨大价值。
缺陷修复更快地发送给客户，新功能更快地进入市场，新想法以较小的增量在市场上进行测试以允许重新定位优先级等。
例如，假设一家公司对其基于软件的产品或服务的新功能有一个大创意。他们已经进行了一些研究，他们了解市场，并且他们相信这个想法将带来强劲的新收入。现在考虑提供该功能的两个选项：
在第一种情况下，如果该功能没有达到预期的市场效果，那么 大量 资金会浪费在客户实际上并不想要的东西上。在第二种情况下，客户不想要它的事实是很早确定的，其余的工作没有优先级。
最终，这些“连续的事情”都是为了消除开发过程的开销。如果一家公司的收入线是一项特定的服务产品，那么理想情况下，他们的所有成本都应该用于该产品。开发流程开销（合并代码、合并后重新测试相同功能、手动部署任务等）实际上并没有对服务的价值做出贡献，因此这些概念试图从流程中消除这些成本。
【讨论】：
我认为我们过度分析了这组“连续”的词组，并且可能会使其复杂化。在这种情况下，连续意味着自动化。对于“连续”附加的其他词，请使用英语作为您的翻译指南，请不要试图使事情复杂化！
在“持续构建”中，我们自动将我们的应用程序构建（写入/编译/链接/等）为特定平台/容器/运行时/等可执行的东西。
“持续集成”是指您的新功能在与另一个实体交互时按预期进行测试和执行。显然，在集成发生之前，必须进行构建，并且还将使用彻底的测试来验证集成。因此，在“持续集成”中，人们使用自动化来为现有的功能增加价值，这种方式不会对现有功能产生负面影响，而是与其很好地集成，从而为整体增加感知价值。
就其英文定义而言，集成意味着事物和谐地运转，因此在代码对话中，我的 add 可以在整体中完美地编译、链接、测试和运行。如果最终产品失败了，你不会称它为集成的东西，对吗？！
在我们的上下文中，“持续部署”是“持续交付”的同义词，因为最终我们已经为客户提供了功能。但是，通过过度分析这一点，我可以说部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了。我们部署了代码，但由于我们没有有效地与利益相关者沟通，我们未能从业务角度交付！我们部署了部队，但我们还没有将承诺的水和食物送到附近的城镇。
如果我要加上“持续过渡”这个词，它会不会有它自己的优点？毕竟，也许它更适合描述代码在环境中的移动，因为它比部署或交付更具有“从/到”的含义，部署或交付可能只意味着一个位置，永远！如果我们不运用常识，这就是我们得到的。
总之，这是很简单的描述（做起来有点……复杂！），只要使用常识，英语就可以了。
【讨论】：
持续集成：不断将开发工作与主分支合并的做法，以便尽可能频繁地测试代码以尽早发现问题。
持续交付：在代码准备好交付后持续向环境交付代码。这可能是分期或生产。这个想法是将产品交付给用户群，该用户群可以是 QA 或客户进行审查和检查。
持续集成阶段的单元测试无法捕捉到所有的错误和业务逻辑，尤其是设计问题，这就是我们需要 QA 或用于测试的暂存环境的原因。
持续部署： 代码准备就绪后立即部署或发布。持续部署需要持续集成和持续交付，否则代码质量将无法在发布中得到保证。
持续部署 ~~ 持续集成 + 持续交付
【讨论】：
持续集成
持续交付
持续部署
CI/CD 是一段旅程。不是目的地。
这些阶段是建议。您可以根据自己的情况调整阶段 业务需要。某些阶段可以针对多种类型重复 测试、安全和性能。根据复杂程度 您的项目和团队的结构，一些阶段可以是 在不同的层次上重复了几次。例如，结尾 一个团队的产品可以成为下一个项目的依赖项 团队。这意味着第一支球队的最终产品随后 在下一个团队的项目中作为工件上演。
脚注：
Practicing Continuous Integration and Continuous Delivery on AWS
【讨论】：
什么是持续集成 持续集成是自动化构建和自动化测试的过程或开发实践，即开发人员需要将其代码多次提交到共享存储库中，每个集成都通过自动化构建和测试进行验证。
如果构建失败/成功，则会通知开发人员，然后他可以采取相关措施。
什么是持续交付 持续交付是我们在通过所有测试并具有将代码推送到生产但尚未部署的所有必需配置的任何时间点保持代码可部署的做法。
什么是持续部署 在 CI 的帮助下，我们为我们的应用程序创建了构建，并准备好推送到生产环境。在这一步中，我们的构建已准备就绪，我们可以使用 CD 将我们的应用程序直接部署到 QA 环境，如果一切顺利，我们可以将相同的构建部署到生产环境。
因此，基本上，持续部署比持续交付更进一步。通过这种做法，通过生产管道所有阶段的每个更改都会发布给您的客户。
持续部署是配置管理和容器化的结合。
配置管理： CM 就是维护服务器的配置，使其与应用程序的需求相兼容。
容器化：容器化是一系列费用，可在整个环境中保持一致性。
【讨论】：
DevOps 是 3C 的组合 - 持续、沟通、协作，这导致了各个行业的主要关注点。
在物联网连接的设备世界中，产品所有者、网络、移动和 QA 等多个 scrum 功能以敏捷的方式在 scrum of scrum 循环中工作，以向最终客户交付产品。
持续集成：多个 scrum 功能在多个端点同时工作
持续交付：通过集成和部署，同时处理向多个客户交付产品。
持续部署：多个产品在多个平台上部署到多个客户。
观看此视频，了解 DevOps 如何实现物联网互联世界：https://youtu.be/nAfZt2t4HqA
【讨论】：
根据我在 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。因此，任何通过自动化测试阶段的代码提交都会自动发布到生产环境中。
注意：这不一定是您的管道应有的样子，但它们可以作为参考。
【讨论】：
让我们保持简短：
CI： 一种软件开发实践，团队成员至少每天集成他们的工作。每个集成都通过自动构建（包括测试）进行验证，以尽可能快地检测错误。 光盘： CD Builds on CI，您可以在其中构建软件，以便随时将软件发布到生产环境中。
【讨论】：