持续集成与持续交付与持续部署
Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
这三个术语有什么区别？我的大学提供以下定义：
持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。
持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！
持续部署 被描述为持续交付后合乎逻辑的下一步：只要产品通过 QA，就自动将其部署到生产环境中！
他们还提供警告：如果您能够持续部署到测试系统，有时也会使用术语“持续部署”。
这一切让我很困惑。任何更详细（或附带示例）的解释都将受到赞赏！
Continuous Integration basically just means that the developer's working copies are synchronized with a shared mainline several times a day.
或者每天不止几次。基本上，只要完成任何给定的离散任务即可。例如，考虑一组开发单个业务应用程序的开发人员。在许多环境中，可能会发生以下情况：
- 一两个开发人员将本地更改保留几天，因为 "it's not ready yet"。
- 一个或两个开发人员在源代码管理中创建分支，以便他们可以处理他们的功能 "without being bothered by other people's changes"。
这些可能会导致问题。糟糕的 code/task 组织导致分支，分支导致合并，合并......导致痛苦。持续集成作为一种实践通过鼓励每个人从同一个共享源工作来解决这个问题。单个工作项目应该足够离散，以便在短时间内（最多几小时）完成。
基本上总体思路是在少量工作中集成一个小的变化。整合一个大的变化是一项不成比例的大量工作。如果以恒定的小步骤完成，集成工作的总量会更小。这使开发人员可以将更多时间用于处理业务可见的功能，而不是开发过程开销。
Continuous Delivery is described as the logical evolution of continuous integration: Always be able to put a product into production!
这遵循了离散的、定义明确的工作项的相同想法。如果有一个单一的主代码库，它只是通过完整的、经过测试的、已知的工作特性以小的增量进行调整，那么该代码库始终是稳定的。自动化测试是这里的关键，它能够证明按下按钮后的稳定性。
需要完成的稳定性工作越少（同样，这是开发过程的开销，应该消除），代码库可以更频繁地推送到任何给定的环境。在许多公司中，部署可能是一个非常艰苦的过程。甚至是为期一周的全员操作。这是昂贵的，并且不会产生任何商业价值。通过采用良好的工作项定义、有效的自动化测试和持续集成，团队可以将代码库自动交付到任何给定环境。
Continuous Deployment is described as the logical next step after continuous delivery: Automatically deploy the product into production whenever it passes QA!
在商业环境中你很少会看到这种情况发生，遇到它时会很高兴。如果代码库可以自动测试并自动部署到任何给定环境，那么，生产环境就像任何其他环境一样。因此，如果团队已经建立到这一点，那么通过始终能够将更新部署到生产环境，就有可能为企业带来重大价值。
更快地向客户发送缺陷修复程序，更快地将新功能推向市场，以更小的增量对新想法进行市场测试以允许重新定向优先级等。
例如，假设一家公司在其基于软件的产品或服务中有一个新功能的好主意。他们做了一些研究，他们了解市场，他们相信这个想法会带来强劲的新收入。现在考虑提供该功能的两个选项：
- 花几个月的时间在一次性分支中开发整个项目。花数周时间将其整合回主代码库。花几天时间测试它。花一天时间部署它。并且只有 然后 开始跟踪生产系统中的实际收入。
- 实现功能的一小部分，一次一个。每周发布一个新的片段。每周获取更多关于实际收入的数据。
在第一种情况下，如果该功能没有达到预期的市场效果，那么 很多 的钱就会浪费在客户实际上并不想要的东西上。在第二种情况下，客户不想要它的事实被确定得非常非常早，其余工作的优先级降低。
最终这些 "continuous things" 都是为了消除开发过程的开销。如果一家公司的收入线是一种特定的服务产品，那么理想情况下，他们的所有成本都应该用于该产品。开发流程开销（合并代码、合并后重新测试相同功能、手动部署任务等）实际上并没有为服务的价值做出贡献，因此这些概念试图从流程中消除这些成本。
持续集成
我同意你们大学的定义。 持续集成 是开发人员如何将代码持续集成到主线的策略 - 而不是频繁集成。
您可能会声称它只是版本控制系统中的一种分支策略。
这与您分配给开发人员的任务大小有关；如果一项任务估计需要 4-5 个工作日，那么开发人员将没有动力在接下来的 4-5 天内交付任何东西，因为他还没有完成任何事情。
所以大小很重要：
small task = continuous integration
big task = frequent integration
理想的任务规模不超过一天的工作量。这样一个开发者自然每天至少有一个集成。
持续交付
持续交付中基本上有三个 学校：
持续交付是持续集成的自然延伸
这所学校，查看 Addison-Wesley "Martin Fowler" signature series 并假设自 2007 年发布以来被称为 “持续集成”，而 2011 年的后续版本被称为“持续交付” 它们可能是与连续 某物.
有关的相同概念的第 1+2 卷
持续交付与敏捷软件开发有关
这所学校认为持续交付就是能够支持敏捷运动中的原则，而不仅仅是作为一个概念性想法或意向书 但在现实生活中是真实的。
抵消 Agile Manifesto 中的第一个原则，其中术语“持续交付”实际上是第一次使用：
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
这所学校声称“持续交付”是一种范例，它涵盖了对您的 "definition of done" 进行自动验证所需的一切。
这所学校承认“持续交付”和流行语或大趋势 "DevOps" 是同一枚硬币的两面，因为它们都试图拥抱或封装这种新范式或方法，而不是只是一个技巧。
持续交付是持续部署的同义词
第三派提倡Continuous Deployment和Continuous Delivery可以互换使用，意思相同
当开发人员准备好某些东西时，它会立即交付给最终用户，这在大多数情况下意味着它应该部署到生产环境中。因此“部署”和“交付”的意思相同。
加入哪个学校
你的大学显然加入了第一所学校，并声称我们指的是同一出版物系列的第 1+2 卷。我认为这是对持续交付一词的误用。
我个人主张理解 持续交付 与实现对敏捷运动所陈述的想法和概念的现实支持有关。所以我加入了一个学派，该学派认为这个术语包含了一个完整的范式——比如“DevOps”。
学派将delivery作为deploy的同义词，主要是创建部署控制台的工具厂商提倡的，试图获得一个术语 持续交付.
的更广泛使用引起了一些炒作
持续部署
对持续部署的关注主要与最终用户对软件更新的访问依赖于此信息的某些集中源的更新以及此集中源并不总是易于更新的领域相关，因为它是单一的或具有（太）本质上的高一致性（网络、SOA、数据库等）。
对于许多生产没有集中信息源（设备、消费产品、客户端安装等）或集中信息源易于更新（应用程序存储工件管理系统、开源存储库等），几乎没有关于持续部署这个术语的炒作。他们只是部署；这不是什么大事 - 这不是需要特别关注的痛苦。
事实上，持续部署并不是每个人都普遍感兴趣的东西，这也是一个论点，即声称“交付”和“部署”是同义词的学校完全错了。因为持续交付实际上对每个人都非常有意义 - 即使您在设备中开发嵌入式软件或为框架发布开源插件。
你们大学关于持续部署是持续交付的自然下一步的定义隐含地假设每个经过 QA 的交付都应该立即可供最终用户使用，这更接近我的部落使用的定义描述术语“连续发布”，这反过来又是另一个概念，通常对每个人都没有意义。
发布可能是一件非常具有战略意义或政治意义的事情，没有理由假设每个人都想一直这样做（除非他们是在线书店或流媒体服务类型的公司）。然而，不一直盲目发布所有内容的公司可能出于各种原因想要成为部署大师，所以他们也做 持续部署 。不是发布到生产，而是 候选发布 到 类生产 环境。
我再次相信你的大学弄错了。他们将“持续部署”误认为是“持续发布”。
持续部署只是能够持续将开发过程的结果移动到可以全面执行功能测试的类似生产环境的学科。
持续交付故事情节
图中的一切都活了过来：
持续集成过程是状态转换图中的前两个动作。这 - 如果成功 - 将启动实现 完成 定义的持续交付管道。部署只是必须在此管道中连续完成的众多操作之一。理想情况下，从开发人员提交 VCS 到流水线确认我们有一个有效的候选发布点，该过程是自动化的。
问题和答案都不符合我简单的思考方式。我是一名顾问，已将这些定义与许多开发团队和 DevOps 人员同步，但我很好奇它如何与整个行业相匹配：
基本上我认为持续交付的敏捷实践就像一个连续统一体：
不连续（全部手动）0% ----> 100% 持续交付价值（全部自动化）
实现持续交付的步骤：
零。当开发人员签入代码时，没有什么是自动化的......如果他们在签入之前编译、运行 或执行任何测试，你就很幸运了。
持续构建： 在每次签入时自动构建，这是第一步，但不会证明新代码的功能集成。
持续集成（CI）： 自动构建和执行至少单元测试以证明新代码与现有代码的集成，但是最好是集成测试（端到端）。
持续部署（CD）：代码通过时自动部署CI至少进入测试环境，最好进入更高的环境，当质量是通过 CI 或在手动测试后将较低的环境标记为通过来证明。即，在某些情况下测试可能是手动的，但升级到下一个环境是自动的。
持续交付： 将系统自动发布和发布到生产环境中。这是用于生产的 CD 以及任何其他配置更改，例如 A/B 测试设置、通知用户新功能、通知支持新版本和更改说明等。
编辑：我想指出的是，在敏捷宣言的第一条原则 (http://agilemanifesto.org/principles.html) and the practice of Continuous Delivery, as seems to be referenced by the context of the question. The principle of continuous delivery is that of striving to reduce the Inventory waste as described in Lean thinking (http://www.miconleansixsigma.com/8-wastes.html) 中引用的 "continuous delivery" 概念之间存在差异。自 2001 年编写敏捷宣言以来，敏捷团队的持续交付 (CD) 实践已经出现了很多年。这种敏捷实践直接解决了原则，尽管它们是不同的东西并且显然很容易混淆。
我认为我们过度分析了“连续”的词组，可能有点复杂了。在这种情况下，连续意味着自动化。对于“continuous”附加的其他词，请使用英语作为翻译指南，请不要试图将事情复杂化！
在“持续构建”中，我们自动将我们的应用程序构建 (write/compile/link/etc) 为特定 platform/container/runtime/etc.
可执行的东西
“持续集成”意味着您的新功能在与另一个实体交互时按预期进行测试和执行。显然，在集成发生之前，必须进行构建，并且还将使用全面测试来验证集成。因此，在“持续集成”中，人们使用自动化为现有功能桶增加价值，其方式不会对现有功能产生负面影响，而是与其很好地集成，从而为整体增加感知价值。
Integration 仅通过其英文定义就意味着事物和谐地结合在一起，因此在代码对话中，我的添加在整体中完美地编译、链接、测试和运行。如果最终产品失败了，你不会称之为集成的东西，对吗？！
在我们的上下文中，“持续部署”是“持续交付”的同义词，因为归根结底我们已经为客户提供了功能。然而，通过过度分析这一点，我可以争辩说部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了。我们部署了代码，但由于我们没有有效地与我们的利益相关者沟通，我们未能从业务角度交付！我们部署了部队，但我们还没有把承诺的水和食物送到附近的城镇。
如果我加上“连续过渡”这个词，它会不会有自己的优点呢？毕竟，也许它更适合描述代码在环境中的移动，因为它比部署或交付更具有“from/to”的含义，部署或交付可能永远只暗示一个位置！如果我们不运用常识，这就是我们得到的结果。
总之，这东西描述起来很简单（做起来有点……复杂！），用常识，英语就可以了。
我认为亚马逊的定义简单易懂。
"持续交付 是一种软件开发方法，其中发布过程是自动化的。每个软件更改都会自动构建、测试并部署到生产环境中。在最终推送到生产环境之前、人员、自动化测试或业务规则决定何时进行最终推送。虽然每个成功的软件更改都可以通过持续交付立即发布到生产中，但并非所有更改都需要立即发布。
持续集成 是一种软件开发实践，其中团队成员使用版本控制系统并将他们的工作经常集成到同一位置，例如主分支。每个更改都是通过测试和其他验证来构建和验证的，以便尽快检测到任何集成错误。 与持续交付相比，持续集成侧重于自动构建和测试代码，持续交付使整个软件发布过程自动化直至生产。"
请查看http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html
DevOps 是 3C 的组合 - 连续、沟通、协作 和这个领导成为各个行业的主要焦点。
在 IoT 连接设备世界中，产品所有者、Web、移动和 QA 等多个 Scrum 功能在一个 Scrum 周期的 Scrum 中以敏捷的方式工作，以将产品交付给最终客户。
Continuous integration: Multiple scrum feature working simultanrouly in multiple endpoints
Continuous delivery: With integration and deployment, delivery of product to multiple customers to be handled at the same time.
Continuous deployment: multiple products deployed to multiple customers at multiple platform.
观看此视频了解 DevOps 如何支持物联网互联世界：https://youtu.be/nAfZt2t4HqA
一张图可以代替很多字：
尽情享受吧！ :-)
# 我已经更新了正确的图片...
Atlassian 发布了关于 Continuous integration vs. continuous delivery vs. continuous deployment 的很好的解释。
简而言之：
持续集成 - 是
每当新提交被推送到分支时，自动构建和测试应用程序。
持续交付 - 是持续集成 + 通过[=38将应用程序部署到生产环境=]（经常向客户发布，但按需发布）。
持续部署 - 是
持续交付但无需人工干预（持续向客户发布）。
持续集成、持续交付和持续部署之间的区别
持续集成：不断将开发工作与主分支合并的做法，以便尽可能频繁地测试代码以尽早发现问题。
持续交付： 一旦代码准备好交付，就将代码持续交付到环境中。这可能是暂存或生产。这个想法是将产品交付给用户群，可以是 QA 或客户进行审查和检查。
持续集成阶段的单元测试无法捕获所有错误和业务逻辑，特别是设计问题，这就是为什么我们需要 QA 或暂存环境进行测试。
持续部署：代码准备就绪后立即部署或发布。持续部署需要持续集成和持续交付，否则发布时代码质量无法保证。
持续部署~~持续集成+持续交付
持续集成
- 自动化（构建签到 + 单元测试）
持续交付
- 持续集成
- 自动化（部署到测试环境+负载测试+集成测试）
- 手动（部署到生产）
持续部署
- 持续交付但自动化（部署到生产）
CI/CD是一段旅程。不是目的地。
These stages are suggestions. You can adapt the stages based on your
business need. Some stages can be repeated for multiple types of
testing, security, and performance. Depending on the complexity of
your project and the structure of your teams, some stages can be
repeated several times at different levels. For example, the end
product of one team can become a dependency in the project of the next
team. This means that the first team’s end product is subsequently
staged as an artifact in the next team’s project.
脚注：
什么是持续集成
持续集成是自动化构建和自动化测试的过程或开发实践，即开发人员需要多次将其代码提交到共享存储库中，其中每个集成都通过自动化构建和测试进行验证。
如果构建 fails/success 会通知开发人员，然后他可以采取相关行动。
什么是持续交付
持续交付是一种实践，我们可以在任何时候保持我们的代码可部署，这些代码已经通过所有测试并具有将代码推送到生产环境所需的所有配置，但尚未部署。
什么是持续部署
在 CI 的帮助下，我们已经为我们的应用程序创建了 s 构建，并准备好将其推向生产。在此步骤中，我们的构建已准备就绪，使用 CD 我们可以将应用程序直接部署到 QA 环境，如果一切顺利，我们可以将相同的构建部署到生产环境。
所以基本上，持续部署比持续交付更进一步。通过这种做法，通过生产管道所有阶段的每个更改都会发布给您的客户。
持续部署是配置管理和容器化的结合。
配置管理： CM 就是维护与应用程序要求兼容的服务器配置。
容器化：容器化是一组通行费，它将在整个环境中保持一致性。
根据我在 Continuous Delivery & DevOps、CI 课程中与 Alex Cowan 一起学到的知识，CD 是产品管道的一部分，它包含从观察到发布产品的时间.
从观察到设计的目标是获得高质量的可测试想法。这部分过程被认为是持续设计。
之后会发生什么，当我们从代码开始时，它被认为是 持续交付 能力，其目的是非常快速地执行想法并向客户发布（您可以阅读 Jez Humble 的书 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 了解更多详情）。以下管道解释了持续集成 (CI) 和持续交付 (CD) 由哪些步骤组成。
持续集成，如Mattias Petter Johansson explains，
is when a software team has habit of doing multiple merges per day and
they have an automated verification system in place to check those
merges for problems.
（您可以观看以下两个视频以使用 CircleCI - Getting started with CircleCI - Continuous Integration P2 and Running CircleCI on Pull Request 获得更实用的概述）。
可以如下指定 CI/CD 管道，从新代码到已发布的产品。
前三个步骤与测试有关，扩展了被测内容的边界。
Continuous Deployment，另一方面，是自动处理Deployment。因此，任何通过自动化测试阶段的代码提交都会自动发布到生产环境中。
注意：这不一定是你的管道应该是什么样子，但它们可以作为参考。
让我们保持简短：
CI:
一种软件开发实践，其中团队成员至少每天整合他们的工作。每个集成都通过自动构建（包括测试）进行验证，以尽快检测错误。
CD:
CD 建立在 CI 之上，您可以在其中以可以随时将软件发布到生产环境的方式构建软件。
这三个术语有什么区别？我的大学提供以下定义：
持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。
持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！
持续部署 被描述为持续交付后合乎逻辑的下一步：只要产品通过 QA，就自动将其部署到生产环境中！
他们还提供警告：如果您能够持续部署到测试系统，有时也会使用术语“持续部署”。
这一切让我很困惑。任何更详细（或附带示例）的解释都将受到赞赏！
Continuous Integration basically just means that the developer's working copies are synchronized with a shared mainline several times a day.
或者每天不止几次。基本上，只要完成任何给定的离散任务即可。例如，考虑一组开发单个业务应用程序的开发人员。在许多环境中，可能会发生以下情况：
- 一两个开发人员将本地更改保留几天，因为 "it's not ready yet"。
- 一个或两个开发人员在源代码管理中创建分支，以便他们可以处理他们的功能 "without being bothered by other people's changes"。
这些可能会导致问题。糟糕的 code/task 组织导致分支，分支导致合并，合并......导致痛苦。持续集成作为一种实践通过鼓励每个人从同一个共享源工作来解决这个问题。单个工作项目应该足够离散，以便在短时间内（最多几小时）完成。
基本上总体思路是在少量工作中集成一个小的变化。整合一个大的变化是一项不成比例的大量工作。如果以恒定的小步骤完成，集成工作的总量会更小。这使开发人员可以将更多时间用于处理业务可见的功能，而不是开发过程开销。
Continuous Delivery is described as the logical evolution of continuous integration: Always be able to put a product into production!
这遵循了离散的、定义明确的工作项的相同想法。如果有一个单一的主代码库，它只是通过完整的、经过测试的、已知的工作特性以小的增量进行调整，那么该代码库始终是稳定的。自动化测试是这里的关键，它能够证明按下按钮后的稳定性。
需要完成的稳定性工作越少（同样，这是开发过程的开销，应该消除），代码库可以更频繁地推送到任何给定的环境。在许多公司中，部署可能是一个非常艰苦的过程。甚至是为期一周的全员操作。这是昂贵的，并且不会产生任何商业价值。通过采用良好的工作项定义、有效的自动化测试和持续集成，团队可以将代码库自动交付到任何给定环境。
Continuous Deployment is described as the logical next step after continuous delivery: Automatically deploy the product into production whenever it passes QA!
在商业环境中你很少会看到这种情况发生，遇到它时会很高兴。如果代码库可以自动测试并自动部署到任何给定环境，那么，生产环境就像任何其他环境一样。因此，如果团队已经建立到这一点，那么通过始终能够将更新部署到生产环境，就有可能为企业带来重大价值。
更快地向客户发送缺陷修复程序，更快地将新功能推向市场，以更小的增量对新想法进行市场测试以允许重新定向优先级等。
例如，假设一家公司在其基于软件的产品或服务中有一个新功能的好主意。他们做了一些研究，他们了解市场，他们相信这个想法会带来强劲的新收入。现在考虑提供该功能的两个选项：
- 花几个月的时间在一次性分支中开发整个项目。花数周时间将其整合回主代码库。花几天时间测试它。花一天时间部署它。并且只有 然后 开始跟踪生产系统中的实际收入。
- 实现功能的一小部分，一次一个。每周发布一个新的片段。每周获取更多关于实际收入的数据。
在第一种情况下，如果该功能没有达到预期的市场效果，那么 很多 的钱就会浪费在客户实际上并不想要的东西上。在第二种情况下，客户不想要它的事实被确定得非常非常早，其余工作的优先级降低。
最终这些 "continuous things" 都是为了消除开发过程的开销。如果一家公司的收入线是一种特定的服务产品，那么理想情况下，他们的所有成本都应该用于该产品。开发流程开销（合并代码、合并后重新测试相同功能、手动部署任务等）实际上并没有为服务的价值做出贡献，因此这些概念试图从流程中消除这些成本。
持续集成
我同意你们大学的定义。 持续集成 是开发人员如何将代码持续集成到主线的策略 - 而不是频繁集成。
您可能会声称它只是版本控制系统中的一种分支策略。
这与您分配给开发人员的任务大小有关；如果一项任务估计需要 4-5 个工作日，那么开发人员将没有动力在接下来的 4-5 天内交付任何东西，因为他还没有完成任何事情。
所以大小很重要：
small task = continuous integration
big task = frequent integration
理想的任务规模不超过一天的工作量。这样一个开发者自然每天至少有一个集成。
持续交付
持续交付中基本上有三个 学校：
持续交付是持续集成的自然延伸
这所学校，查看 Addison-Wesley "Martin Fowler" signature series 并假设自 2007 年发布以来被称为 “持续集成”，而 2011 年的后续版本被称为“持续交付” 它们可能是与连续 某物.
有关的相同概念的第 1+2 卷持续交付与敏捷软件开发有关
这所学校认为持续交付就是能够支持敏捷运动中的原则，而不仅仅是作为一个概念性想法或意向书 但在现实生活中是真实的。
抵消 Agile Manifesto 中的第一个原则，其中术语“持续交付”实际上是第一次使用：
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
这所学校声称“持续交付”是一种范例，它涵盖了对您的 "definition of done" 进行自动验证所需的一切。
这所学校承认“持续交付”和流行语或大趋势 "DevOps" 是同一枚硬币的两面，因为它们都试图拥抱或封装这种新范式或方法，而不是只是一个技巧。
持续交付是持续部署的同义词
第三派提倡Continuous Deployment和Continuous Delivery可以互换使用，意思相同
当开发人员准备好某些东西时，它会立即交付给最终用户，这在大多数情况下意味着它应该部署到生产环境中。因此“部署”和“交付”的意思相同。
加入哪个学校
你的大学显然加入了第一所学校，并声称我们指的是同一出版物系列的第 1+2 卷。我认为这是对持续交付一词的误用。
我个人主张理解 持续交付 与实现对敏捷运动所陈述的想法和概念的现实支持有关。所以我加入了一个学派，该学派认为这个术语包含了一个完整的范式——比如“DevOps”。
学派将delivery作为deploy的同义词，主要是创建部署控制台的工具厂商提倡的，试图获得一个术语 持续交付.
的更广泛使用引起了一些炒作持续部署
对持续部署的关注主要与最终用户对软件更新的访问依赖于此信息的某些集中源的更新以及此集中源并不总是易于更新的领域相关，因为它是单一的或具有（太）本质上的高一致性（网络、SOA、数据库等）。
对于许多生产没有集中信息源（设备、消费产品、客户端安装等）或集中信息源易于更新（应用程序存储工件管理系统、开源存储库等），几乎没有关于持续部署这个术语的炒作。他们只是部署；这不是什么大事 - 这不是需要特别关注的痛苦。
事实上，持续部署并不是每个人都普遍感兴趣的东西，这也是一个论点，即声称“交付”和“部署”是同义词的学校完全错了。因为持续交付实际上对每个人都非常有意义 - 即使您在设备中开发嵌入式软件或为框架发布开源插件。
你们大学关于持续部署是持续交付的自然下一步的定义隐含地假设每个经过 QA 的交付都应该立即可供最终用户使用，这更接近我的部落使用的定义描述术语“连续发布”，这反过来又是另一个概念，通常对每个人都没有意义。
发布可能是一件非常具有战略意义或政治意义的事情，没有理由假设每个人都想一直这样做（除非他们是在线书店或流媒体服务类型的公司）。然而，不一直盲目发布所有内容的公司可能出于各种原因想要成为部署大师，所以他们也做 持续部署 。不是发布到生产，而是 候选发布 到 类生产 环境。
我再次相信你的大学弄错了。他们将“持续部署”误认为是“持续发布”。
持续部署只是能够持续将开发过程的结果移动到可以全面执行功能测试的类似生产环境的学科。
持续交付故事情节
图中的一切都活了过来：
持续集成过程是状态转换图中的前两个动作。这 - 如果成功 - 将启动实现 完成 定义的持续交付管道。部署只是必须在此管道中连续完成的众多操作之一。理想情况下，从开发人员提交 VCS 到流水线确认我们有一个有效的候选发布点，该过程是自动化的。
问题和答案都不符合我简单的思考方式。我是一名顾问，已将这些定义与许多开发团队和 DevOps 人员同步，但我很好奇它如何与整个行业相匹配：
基本上我认为持续交付的敏捷实践就像一个连续统一体：
不连续（全部手动）0% ----> 100% 持续交付价值（全部自动化）
实现持续交付的步骤：
零。当开发人员签入代码时，没有什么是自动化的......如果他们在签入之前编译、运行 或执行任何测试，你就很幸运了。
持续构建： 在每次签入时自动构建，这是第一步，但不会证明新代码的功能集成。
持续集成（CI）： 自动构建和执行至少单元测试以证明新代码与现有代码的集成，但是最好是集成测试（端到端）。
持续部署（CD）：代码通过时自动部署CI至少进入测试环境，最好进入更高的环境，当质量是通过 CI 或在手动测试后将较低的环境标记为通过来证明。即，在某些情况下测试可能是手动的，但升级到下一个环境是自动的。
持续交付： 将系统自动发布和发布到生产环境中。这是用于生产的 CD 以及任何其他配置更改，例如 A/B 测试设置、通知用户新功能、通知支持新版本和更改说明等。
编辑：我想指出的是，在敏捷宣言的第一条原则 (http://agilemanifesto.org/principles.html) and the practice of Continuous Delivery, as seems to be referenced by the context of the question. The principle of continuous delivery is that of striving to reduce the Inventory waste as described in Lean thinking (http://www.miconleansixsigma.com/8-wastes.html) 中引用的 "continuous delivery" 概念之间存在差异。自 2001 年编写敏捷宣言以来，敏捷团队的持续交付 (CD) 实践已经出现了很多年。这种敏捷实践直接解决了原则，尽管它们是不同的东西并且显然很容易混淆。
我认为我们过度分析了“连续”的词组，可能有点复杂了。在这种情况下，连续意味着自动化。对于“continuous”附加的其他词，请使用英语作为翻译指南，请不要试图将事情复杂化！
在“持续构建”中，我们自动将我们的应用程序构建 (write/compile/link/etc) 为特定 platform/container/runtime/etc.
可执行的东西“持续集成”意味着您的新功能在与另一个实体交互时按预期进行测试和执行。显然，在集成发生之前，必须进行构建，并且还将使用全面测试来验证集成。因此，在“持续集成”中，人们使用自动化为现有功能桶增加价值，其方式不会对现有功能产生负面影响，而是与其很好地集成，从而为整体增加感知价值。
Integration 仅通过其英文定义就意味着事物和谐地结合在一起，因此在代码对话中，我的添加在整体中完美地编译、链接、测试和运行。如果最终产品失败了，你不会称之为集成的东西，对吗？！
在我们的上下文中，“持续部署”是“持续交付”的同义词，因为归根结底我们已经为客户提供了功能。然而，通过过度分析这一点，我可以争辩说部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了。我们部署了代码，但由于我们没有有效地与我们的利益相关者沟通，我们未能从业务角度交付！我们部署了部队，但我们还没有把承诺的水和食物送到附近的城镇。
如果我加上“连续过渡”这个词，它会不会有自己的优点呢？毕竟，也许它更适合描述代码在环境中的移动，因为它比部署或交付更具有“from/to”的含义，部署或交付可能永远只暗示一个位置！如果我们不运用常识，这就是我们得到的结果。
总之，这东西描述起来很简单（做起来有点……复杂！），用常识，英语就可以了。
我认为亚马逊的定义简单易懂。
"持续交付 是一种软件开发方法，其中发布过程是自动化的。每个软件更改都会自动构建、测试并部署到生产环境中。在最终推送到生产环境之前、人员、自动化测试或业务规则决定何时进行最终推送。虽然每个成功的软件更改都可以通过持续交付立即发布到生产中，但并非所有更改都需要立即发布。
持续集成 是一种软件开发实践，其中团队成员使用版本控制系统并将他们的工作经常集成到同一位置，例如主分支。每个更改都是通过测试和其他验证来构建和验证的，以便尽快检测到任何集成错误。 与持续交付相比，持续集成侧重于自动构建和测试代码，持续交付使整个软件发布过程自动化直至生产。"
请查看http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html
DevOps 是 3C 的组合 - 连续、沟通、协作 和这个领导成为各个行业的主要焦点。
在 IoT 连接设备世界中，产品所有者、Web、移动和 QA 等多个 Scrum 功能在一个 Scrum 周期的 Scrum 中以敏捷的方式工作，以将产品交付给最终客户。
Continuous integration: Multiple scrum feature working simultanrouly in multiple endpoints
Continuous delivery: With integration and deployment, delivery of product to multiple customers to be handled at the same time.
Continuous deployment: multiple products deployed to multiple customers at multiple platform.
观看此视频了解 DevOps 如何支持物联网互联世界：https://youtu.be/nAfZt2t4HqA
一张图可以代替很多字：
尽情享受吧！ :-)
# 我已经更新了正确的图片...
Atlassian 发布了关于 Continuous integration vs. continuous delivery vs. continuous deployment 的很好的解释。
简而言之：
持续集成 - 是 每当新提交被推送到分支时，自动构建和测试应用程序。
持续交付 - 是持续集成 + 通过[=38将应用程序部署到生产环境=]（经常向客户发布，但按需发布）。
持续部署 - 是 持续交付但无需人工干预（持续向客户发布）。
持续集成、持续交付和持续部署之间的区别
持续集成：不断将开发工作与主分支合并的做法，以便尽可能频繁地测试代码以尽早发现问题。
持续交付： 一旦代码准备好交付，就将代码持续交付到环境中。这可能是暂存或生产。这个想法是将产品交付给用户群，可以是 QA 或客户进行审查和检查。
持续集成阶段的单元测试无法捕获所有错误和业务逻辑，特别是设计问题，这就是为什么我们需要 QA 或暂存环境进行测试。
持续部署：代码准备就绪后立即部署或发布。持续部署需要持续集成和持续交付，否则发布时代码质量无法保证。
持续部署~~持续集成+持续交付
持续集成
- 自动化（构建签到 + 单元测试）
持续交付
- 持续集成
- 自动化（部署到测试环境+负载测试+集成测试）
- 手动（部署到生产）
持续部署
- 持续交付但自动化（部署到生产）
CI/CD是一段旅程。不是目的地。
These stages are suggestions. You can adapt the stages based on your business need. Some stages can be repeated for multiple types of testing, security, and performance. Depending on the complexity of your project and the structure of your teams, some stages can be repeated several times at different levels. For example, the end product of one team can become a dependency in the project of the next team. This means that the first team’s end product is subsequently staged as an artifact in the next team’s project.
脚注：
什么是持续集成 持续集成是自动化构建和自动化测试的过程或开发实践，即开发人员需要多次将其代码提交到共享存储库中，其中每个集成都通过自动化构建和测试进行验证。
如果构建 fails/success 会通知开发人员，然后他可以采取相关行动。
什么是持续交付 持续交付是一种实践，我们可以在任何时候保持我们的代码可部署，这些代码已经通过所有测试并具有将代码推送到生产环境所需的所有配置，但尚未部署。
什么是持续部署 在 CI 的帮助下，我们已经为我们的应用程序创建了 s 构建，并准备好将其推向生产。在此步骤中，我们的构建已准备就绪，使用 CD 我们可以将应用程序直接部署到 QA 环境，如果一切顺利，我们可以将相同的构建部署到生产环境。
所以基本上，持续部署比持续交付更进一步。通过这种做法，通过生产管道所有阶段的每个更改都会发布给您的客户。
持续部署是配置管理和容器化的结合。
配置管理： CM 就是维护与应用程序要求兼容的服务器配置。
容器化：容器化是一组通行费，它将在整个环境中保持一致性。
根据我在 Continuous Delivery & DevOps、CI 课程中与 Alex Cowan 一起学到的知识，CD 是产品管道的一部分，它包含从观察到发布产品的时间.
从观察到设计的目标是获得高质量的可测试想法。这部分过程被认为是持续设计。
之后会发生什么，当我们从代码开始时，它被认为是 持续交付 能力，其目的是非常快速地执行想法并向客户发布（您可以阅读 Jez Humble 的书 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 了解更多详情）。以下管道解释了持续集成 (CI) 和持续交付 (CD) 由哪些步骤组成。
持续集成，如Mattias Petter Johansson explains，
is when a software team has habit of doing multiple merges per day and they have an automated verification system in place to check those merges for problems.
（您可以观看以下两个视频以使用 CircleCI - Getting started with CircleCI - Continuous Integration P2 and Running CircleCI on Pull Request 获得更实用的概述）。
可以如下指定 CI/CD 管道，从新代码到已发布的产品。
前三个步骤与测试有关，扩展了被测内容的边界。
Continuous Deployment，另一方面，是自动处理Deployment。因此，任何通过自动化测试阶段的代码提交都会自动发布到生产环境中。
注意：这不一定是你的管道应该是什么样子，但它们可以作为参考。
让我们保持简短：
CI: 一种软件开发实践，其中团队成员至少每天整合他们的工作。每个集成都通过自动构建（包括测试）进行验证，以尽快检测错误。 CD: CD 建立在 CI 之上，您可以在其中以可以随时将软件发布到生产环境的方式构建软件。