这三个术语有什么区别？我的大学提供以下定义：
Continuous Integration 基本上只是意味着开发人员的工作副本每天都会与共享主线同步几次 .
Continuous Delivery 被描述为持续集成的逻辑演变：始终能够将产品投入 生产环境 ！
Continuous Deployment 被描述为持续交付后的逻辑下一步：每当通过QA时自动将产品部署到 生产环境 中！
它们还提供警告：如果您能够连续部署到测试系统，有时也会使用术语“持续部署” .
所有这些让我感到困惑 . 任何更详细（或附带一个例子）的解释表示赞赏！
10 回答
持续集成
我同意你大学的定义 . 持续集成是开发人员如何持续地将代码集成到主线的策略 - 而不是经常 .
您可能会声称它只是您的版本控制系统中的分支策略 .
它与您分配给开发人员的任务的大小有关;如果一项任务估计需要4-5个人日，那么开发人员将不会煽动在接下来的4-5天内交付任何东西，因为他还没有做任何事情 - 但是 .
因此尺寸很重要：
理想的任务规模不超过一天的工作量 . 这样开发人员每天至少会有一次集成 .
持续交付
持续交付中基本上有三所学校：
Continuous Delivery is a natural extension of Continuous Integration
这所学校，看看Addison-Wesley "Martin Fowler" signature series，并假设自2007年版本被称为"Continuous Integration"并且2011年被称为"Continuous Delivery"之后，它们可能是与连续性事物有关的概念性概念的第1卷 .
Continuous Delivery has to do with Agile Software Development
这所学校的观点是，持续交付的全部意义在于能够支持敏捷运动中的原则，不仅仅是作为一个概念性的想法或一个意向书，而是为了现实生活中的真实 .
在Agile Manifesto中第一个原则采用偏移量，其中第一次使用术语"continuous delivery"：
这所学校声称"Continuous Delivery"是一个范例，包含了实现"definition of done"自动验证所需的一切 .
这所学校接受"Continuous Delivery"和流行词或大趋势"DevOps"是同一枚硬币的翻转面，因为它们都试图接受或封装这种新的范式或方法，而不仅仅是一种技术 .
Continuous Delivery is a synonym to Continuous Deployment
第三所学校主张持续部署和持续交付可以互换使用，意思相同 .
当某些东西在开发人员手中准备就绪时，它会立即传递给最终用户，这在大多数情况下意味着它应该部署到 生产环境 环境中 . 因此“部署”和“交付”意味着相同 .
加入哪所学校
你的大学明显加入了第一所学校，声称我们指的是同一出版物系列的第1卷 . 我的观点是，这是滥用持续交付这一术语 .
我个人主张理解，持续交付与实现对敏捷运动所提出的想法和概念的现实支持有关 . 所以我加入了学校，说这个词包含了一个完整的范例 - 比如"DevOps" .
使用交付作为部署同义词的学校主要由创建部署控制台的工具供应商提倡，试图从更广泛使用术语持续交付中获得一些宣传 .
持续部署
对持续部署的关注主要与最终用户访问软件更新依赖于此信息的某些集中源更新以及此集中源不易更新的域相关，因为它是单片或具有（太高）一致性本质上（网络，SOA，数据库等） .
对于许多生成软件的域，其中没有集中的信息源（设备，消费者产品，客户端安装等）或者集中的信息源易于更新（应用程序存储工件管理系统，开源存储库等） . ），几乎没有任何关于“持续部署”一词的炒作 . 他们只是部署;这不是一件大事 - 这不是需要特别关注的痛苦 .
持续部署不是每个人都普遍感兴趣的事实也是一个论点，即声称“交付”和“部署”是同义词的学校完全错了 . 因为持续交付实际上对每个人都非常有意义 - 即使您在设备中进行嵌入式软件或发布开源插件的框架 .
您的大学定义持续部署是持续交付的自然下一步隐含地假设每个QA的交付应该立即可供最终用户使用，更接近我的部落用来描述术语“连续”的定义发布“，反过来，这是另一个对每个人都没有意义的概念 .
发布可能是一个非常具有战略性或政治性的事情，并且没有理由假设每个人都希望一直这样做（除非他们是在线书店，流媒体服务类型的公司） . 尽管如此，那些不会盲目地一直发布所有内容的公司可能有许多原因，他们无论如何都希望成为部署的主人，因此他们也会进行持续部署 . 不是发布到 生产环境 ，而是发布候选者到 生产环境 环境 .
我再次相信你的大学弄错了 . 他们误以为“持续发布”的“持续部署” .
Continuous deployment is simply the discipline of continuously being able to move the result of a development process to a production-like environment where functional testing can be executed in full scale.
持续交付故事情节
在图片中，一切都活跃起来：
持续集成过程是状态转换图中的前两个操作 . 其中 - 如果成功 - 启动实现完成定义的Continuous Delivery管道 . 部署只是必须在此管道中不断完成的许多操作之一 . 理想情况下，从开发人员提交到VCS的位置到管道确认我们拥有有效的候选发布版本的点，该过程是自动进行的 .
问题和答案都不符合我简单的思考方式 . 我是一名顾问，并将这些定义与许多开发团队和DevOps人员进行了同步，但我很好奇它与整个行业的匹配程度：
基本上我认为连续交付的敏捷实践就像一个连续统一体：
不连续（一切手动）0％----> 100％持续交付 Value （一切自动化）
持续交付的步骤：
零 . 开发人员检查代码时没有什么是自动化的......如果他们在办理登机手续之前编译，运行或执行任何测试，那么你很幸运 .
Continuous Build: 自动构建每次签入，这是第一步，但没有什么可以证明新代码的功能集成 .
Continuous Integration (CI): 自动构建和执行至少单元测试，以证明新代码与现有代码的集成，但最好是集成测试（端到端） .
当代码至少将CI传递到测试环境时，自动部署自动部署，当通过CI或通过在手动测试后将较低环境标记为PASSED来证明质量时，优选地进入更高环境.
Continuous Deployment (CD): 在某些情况下，测试可能是手动的，但是自动推广到下一个环境 .
Continuous Delivery: 自动发布并将系统发布到 生产环境 中 . 这是CD投入 生产环境 以及任何其他配置更改，如A / B测试设置，向用户通知新功能，通知支持新版本和更改注释等 .
编辑：我想指出，敏捷宣言的第一个原则（http://agilemanifesto.org/principles.html）中引用的"continuous delivery"的概念与持续传递的实践之间存在差异，这似乎是问题的背景所引用的 . 持续交付的原则是努力减少库存浪费，如精益思想（http://www.miconleansixsigma.com/8-wastes.html）所述 . 自敏捷宣言于2001年编写以来，灵活团队持续交付（CD）的实践已经出现多年 . 这种敏捷实践直接解决了这一原则，尽管它们是不同的东西，显然很容易混淆 .
我认为 amazon definition 很简单易懂 .
“ Continuous delivery 是一种软件开发方法，其中发布过程是自动化的 . 每个软件更改都会自动构建，测试并部署到 生产环境 中 . 在最终推向 生产环境 之前，一个人，一个自动化测试或业务规则决定何时最终应该发生推动 . 虽然每次成功的软件更改都可以通过持续交付立即发布到 生产环境 中，但并不是所有的更改都需要立即发布 .
Continuous integration 是一种软件开发实践，团队成员使用版本控制系统并将其工作频繁地集成到同一位置，例如主分支 . 每个更改都是通过测试和其他验证构建和验证的，以便尽快检测到任何集成错误 . Continuous integration is focused on automatically building and testing code, as compared to continuous delivery, which automates the entire software release process up to production . “
请查看http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html
或者每天多次 . 基本上，任何给定的离散任务都经常完成 . 例如，考虑一个开发单一业务的开发团队应用 . 在许多环境中，可能会发生以下情况：
一两个开发人员在几天内保留本地更改，因为"it's not ready yet" .
一个或两个开发人员在源代码管理中创建分支，以便他们可以处理他们的功能"without being bothered by other people's changes" .
这些可能会导致问题 . 糟糕的代码/任务组织导致分支，分支导致合并，合并......导致痛苦 . 持续集成作为一种实践通过鼓励每个人使用相同的共享源来解决这个问题 . 个别工作项目应足够离散，以便在短时间内完成（最多几小时） .
基本上，一般的想法是在少量工作中集成一个小的变化 . 整合大量变化是一项不成比例的大量工作 . 如果以恒定的小步骤完成，集成工作的总量会更小 . 这使开发人员可以将更多时间用于业务可见功能而不是开发流程开销 .
这遵循了离散的，明确定义的工作项目的相同想法 . 如果只有一个主代码库只能通过完整，经过测试的已知工作特性以较小的增量进行调整，那么该代码库始终是稳定的 . 自动测试是关键，能够通过按下按钮来证明稳定性 .
需要完成的稳定工作越少（同样，开发过程开销并且应该被消除），代码库可以更频繁地推送到任何给定的环境 . 在许多公司中，部署可能是一个非常艰苦的过程 . 即使是为期一周的全副手操作 . 这很昂贵，没有商业 Value . 通过采用良好的工作项定义，有效的自动化测试和持续集成，团队可以自动将代码库交付到任何给定的环境 .
你很少会在商业环境中看到这种情况，遇到它时会非常高兴 . 如果代码库可以自动测试并自动部署到任何给定的环境，那么， 生产环境 就像任何其他环境一样 . 因此，如果团队已经 Build 起来，那么通过始终能够将更新部署到 生产环境 中，可以为业务带来巨大 Value .
缺陷修复程序更快地发送给客户，新功能更快地到达市场，新的想法以较小的增量对市场进行测试，以允许重定向优先级等 .
例如，假设一家公司对其基于软件的产品或服务中的新功能有一个很大的想法 . 他们已经做了一些研究，他们了解市场，他们相信这个想法将带来强劲的新收入 . 现在考虑提供该功能的两个选项：
花几个月在一次性分支中开发整个事物 . 花几周时间将它集成到主代码库中 . 花几天时间测试一下 . 花一天时间部署它 . 然后才开始跟踪 生产环境 系统中的实际收入 .
一次一个地实现该功能的一小部分 . 每周发布一个新的一块 . 每周获得更多实际收入数据 .
在第一种情况下，如果该功能没有达到预期的市场效果，那么就会浪费大量资金来消费客户，因为他们希望它能够更早地确定，并且其余的工作都是非优先级的 .
最终，这些“连续的事物”都是为了消除开发过程的开销 . 如果公司的收入来源是特定的服务产品，那么理想情况下，他们的所有成本都应该用于该产品 . 开发流程开销（合并代码，合并后重新测试相同的功能，手动部署任务等）实际上并没有对服务的 Value 做出贡献，因此这些概念试图从流程中消除这些成本 .
Atlassian发布了关于Continuous integration vs. continuous delivery vs. continuous deployment的一个很好的解释 .
简而言之：
Continuous Integration - 每当新提交被推入分支时，都是自动构建和测试应用程序 .
Continuous Delivery - 是持续集成 + 通过"clicking on a button"将应用程序部署到 生产环境 中（通常是按需发布给客户） .
Continuous Deployment - 是持续交付但没有人为干预（正在向客户发布） .
One graph can replace many words:
请享用！ :-)
＃我已更新正确的图片...
持续集成，持续交付和持续部署之间的区别
我认为我们过度分析并且可能使一些“连续”的单词变得复杂 . 在这种情况下，连续意味着自动对于附加到“连续”的其他单词，请使用英语作为翻译指导，请不要试图使事情复杂化！在“连续构建”中，我们自动构建（编写/编译/链接/等）我们的应用程序，使其成为特定平台/容器/运行时/等可执行的东西 . “持续集成”意味着您的新功能在与其他实体交互时测试并按预期执行 . 显然，在进行集成之前，必须进行构建，并且还将使用全面测试来验证集成 . 因此，在“持续集成”中，人们使用自动化来增加现有功能桶的 Value ，这种方式不会对现有功能产生负面影响，而是与其良好集成，从而为整体增加感知 Value . 通过纯粹的英语定义，整合意味着和谐地协调事物，所以在代码谈话中我添加编译，链接，测试并在整体中完美地运行 . 如果最终产品失败，你不会把它称为集成，对吗？！在我们的上下文中，“持续部署”是“持续交付”的同义词，因为在一天结束时我们已经为客户提供了功能 . 然而，通过对此进行过度分析，我可以说部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了 . 我们部署了代码但由于我们没有有效地与利益相关方沟通，我们无法从业务角度提供服务！我们部署了部队，但我们没有将承诺的水和食物送到附近的城镇 . 如果我要添加“持续转换”术语，它会有自己的优点吗？毕竟，也许它更适合描述代码在环境中的移动，因为它具有“从/到”的内涵，而不仅仅是部署或交付，这可能只是意味着一个位置，永远！如果我们不运用常识，这就是我们得到的 .
总而言之，这是一个简单的描述（做起来更复杂！），只是使用常识，英语，你会没事的 .
DevOps是3C的组合 - continuous ， communication ， collaboration ，这导致各个行业的主要焦点 .
在物联网连接设备领域，产品所有者，网络，移动和QA等多种Scrum功能以灵活的方式在Scrum周期的混乱中工作，以向最终客户提供产品 .
观看此内容，了解DevOps如何实现物联网连接世界：https://youtu.be/nAfZt2t4HqA
Continuous Integration: 不断地将开发工作与主分支合并的做法，以便尽可能经常地对代码进行测试以及早发现问题 .
Continuous Delivery: 代码准备发布后，将代码连续交付到环境中 . 这可能是分期或 生产环境 . 我们的想法是将产品交付给用户群，可以是QA或客户进行审查和检查 .
持续集成阶段的单元测试无法捕获所有错误和业务逻辑，特别是设计问题，这就是我们需要QA或测试的暂存环境的原因 .
Continuous Deployment: 在发布时保证代码的部署或发布 .
Continuous Deployment ~~ Continuous Integration + Continuous Deplivery