这三个术语有什么区别？我的大学提供以下定义：
持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。
持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！
持续部署被描述为持续交付之后合乎逻辑的下一步：只要产品通过 QA，就自动将产品部署到生产中！
它们还提供警告：如果您能够持续部署到测试系统，有时也会使用术语“持续部署”。
这一切让我感到困惑。任何更详细（或附带示例）的解释表示赞赏！
问问题
147349 次
14 回答
371
持续集成
我同意你们大学的定义。持续集成是开发人员如何将代码持续集成到主线的一种策略 - 而不是频繁集成。
您可能会声称它只是您的版本控制系统中的一种分支策略。
它与您分配给开发人员的任务的大小有关；如果一项任务估计需要 4-5 个工作日，那么开发人员将不会在接下来的 4-5 天内交付任何东西，因为他还没有完成任何事情。
所以尺寸很重要：
small task = continuous integration
big task = frequent integration
理想的任务规模不大于一天的工作量。这样，开发人员自然会每天至少进行一次集成。
持续交付
持续交付中基本上有三个流派：
持续交付是持续集成的自然延伸
这所学校着眼于Addison-Wesley “Martin Fowler” 签名系列，并假设自 2007 年发布以来被称为“持续集成”，而随后在 2011 年发布的版本被称为“持续交付”，它们可能是第 1+2 卷具有与连续事物有关的相同概念。
持续交付与敏捷软件开发有关
这所学校的观点是，持续交付就是能够支持敏捷运动中的原则，而不仅仅是作为概念性想法或意向书，而是在现实生活中实现。
抵消敏捷宣言中的第一条原则，其中第一次实际使用了“持续交付”一词：
我们的首要任务是通过早期和持续交付有价值的软件来满足客户。
这所学校声称“持续交付”是一种范式，它包含实现对“完成的定义”的自动验证所需的一切。
这所学校接受“持续交付”和流行词或大趋势“DevOps”是同一枚硬币的反面，因为它们都试图拥抱或封装这种新的范式或方法，而不仅仅是一种技术。
持续交付是持续部署的同义词
第三派主张持续部署和持续交付可以互换使用，表示同一件事。
当开发人员准备好某些东西时，它会立即交付给最终用户，这在大多数情况下意味着它应该部署到生产环境中。因此“部署”和“交付”的含义相同。
加入哪个学校
你的大学显然加入了第一所学校，并声称我们指的是同一出版物系列的第 1+2 卷。我的观点是，这是对“持续交付”一词的误用。
我个人主张理解持续交付与实现对敏捷运动所陈述的想法和概念的现实支持有关。所以我加入了这所学校，它说这个词包含了一个完整的范式——比如“DevOps”。
使用交付作为部署的同义词的学校主要由创建部署控制台的工具供应商提倡，试图从更广泛使用的术语持续交付中获得一些炒作。
持续部署
对持续部署的关注主要与最终用户对软件更新的访问依赖于对这些信息的某些集中源的更新以及这个集中源并不总是容易更新的领域相关，因为它是单一的或具有（太）高一致性本质上（Web、SOA、数据库等）。
对于许多生产软件的领域，这些领域没有集中的信息源（设备、消费产品、客户端安装等）或集中的信息源易于更新（应用商店工件管理系统、开源存储库等）。 )，几乎没有关于持续部署这个术语的炒作。他们只是部署；这不是什么大事——这不是需要特别关注的痛苦。
持续部署并不是每个人都普遍感兴趣的事实，这也是一个论点，声称“交付”和“部署”是同义词的学校完全错了。因为持续交付实际上对每个人都非常有意义——即使您正在设备中开发嵌入式软件或发布框架的开源插件。
贵校关于持续部署是持续交付的自然下一步的定义隐含地假设每个经过 QA 的交付都应该立即可供最终用户使用，这更接近我的部落用来描述术语“持续”的定义释放”，这反过来又是另一个对每个人都没有普遍意义的概念。
发布可能是非常具有战略意义或政治性的事情，没有理由假设每个人都想一直这样做（除非他们是在线书店或流媒体服务类型的公司）。尽管如此，那些不总是盲目地发布所有东西的公司可能有很多理由让他们想成为部署大师，所以他们也做持续部署。不是发布到生产环境，而是发布候选到生产环境。
我再次相信你的大学弄错了。他们将“持续部署”误认为“持续发布”。
持续部署只是将开发过程的结果持续转移到可以全面执行功能测试的类似生产环境的学科。
持续交付故事情节
在图片中，一切都变得生动起来：
持续集成过程是状态转换图中的前两个动作。如果成功的话，哪个会启动实现done 定义的持续交付管道。部署只是此管道中必须连续完成的众多操作之一。理想情况下，从开发人员提交到 VCS 到流水线确认我们有一个有效的候选版本，这个过程是自动化的。
于 2015-02-20T11:39:05.640 回答
94
问题和答案都不符合我简单的思考方式。我是一名顾问，已经与许多开发团队和 DevOps 人员同步了这些定义，但我很好奇它如何与整个行业匹配：
基本上，我认为持续交付的敏捷实践就像一个连续体：
不连续（一切手动） 0% ----> 100% 持续交付价值（一切自动化）
持续交付的步骤：
零。当开发人员签入代码时，没有任何事情是自动化的……如果他们在签入之前已经编译、运行或执行了任何测试，那么你很幸运。
持续构建：每次签入时自动构建，这是第一步，但不能证明新代码的功能集成。
持续集成 (CI)：至少自动构建和执行单元测试，以证明新代码与现有代码的集成，但最好是集成测试（端到端）。
持续部署 (CD)：当代码至少通过 CI 进入测试环境时自动部署，最好是通过 CI 证明质量或在手动测试后将较低环境标记为 PASSED 时进入更高环境。IE，在某些情况下测试可能是手动的，但升级到下一个环境是自动的。
持续交付：自动发布系统并将其发布到生产中。这是投入生产的 CD 以及任何其他配置更改，例如 A/B 测试设置、新功能通知用户、新版本支持通知和更改说明等。
编辑：我想指出敏捷宣言第一原则（http://agilemanifesto.org/principles.html）中引用的“持续交付”概念与持续交付实践之间存在差异，正如问题的上下文所引用的那样。持续交付的原则是努力减少库存浪费，如精益思想 ( http://www.miconleansixsigma.com/8-wastes.html ) 中所述。自 2001 年编写敏捷宣言以来，敏捷团队的持续交付 (CD) 实践已经出现了很多年。这种敏捷实践直接解决了这一原则，尽管它们是不同的东西，而且显然很容易混淆。
于 2016-08-12T16:02:44.377 回答
71
我认为亚马逊的定义简单易懂。
“持续交付是一种软件开发方法，其中发布过程是自动化的。每个软件更改都是自动构建、测试和部署到生产中的。在最终推向生产之前，一个人、一个自动化测试或一个业务规则决定何时发布最终的推动应该发生。虽然每个成功的软件更改都可以立即发布到生产并持续交付，但并非所有更改都需要立即发布。
持续集成是一种软件开发实践，团队成员使用版本控制系统并经常将他们的工作集成到同一位置，例如主分支。每个更改都通过测试和其他验证来构建和验证，以便尽快检测任何集成错误。与持续交付相比，持续集成专注于自动构建和测试代码，后者将整个软件发布过程自动化，直至生产。”
请查看http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html
于 2016-11-09T07:58:50.020 回答
57
Atlassian 对持续集成、持续交付和持续部署进行了很好的解释。
简而言之：
持续集成- 每当新提交被推送到分支时，自动构建和测试应用程序。
持续交付- 是持续集成 +通过“单击按钮”将应用程序部署到生产环境（通常是根据需要发布给客户）。
持续部署- 是 持续交付，但没有人工干预（正在向客户发布）。
于 2017-08-29T09:42:44.060 回答
36
持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。
或每天数次以上。基本上，只要完成任何给定的离散任务。例如，考虑一个开发单个业务应用程序的开发团队。在许多环境中，可能会发生以下情况：
- 一两个开发人员将本地更改保留几天，因为“它还没有准备好”。
- 一两个开发人员在源代码控制中创建分支，这样他们就可以“不受其他人的更改打扰”来处理他们的功能。
这些可能会导致问题。糟糕的代码/任务组织导致分支，分支导致合并，合并......导致痛苦。作为一种实践的持续集成通过鼓励每个人从同一个共享源中工作来解决这个问题。各个工作项目应该足够离散，以便在短时间内（最多几小时）完成。
基本上，总体思路是在少量工作中集成一个小的变化。集成一个大的变化是一项不成比例的大量工作。如果以恒定的小步骤完成，集成工作的总量会更小。这允许开发人员将更多时间花在业务可见的功能上，而不是开发流程开销。
持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！
这遵循了离散的、明确定义的工作项的相同想法。如果有一个单一的主代码库，它只通过完整的、经过测试的、已知的工作特性进行小幅调整，那么该代码库总是稳定的。自动化测试是这里的关键，它能够通过按下按钮来证明稳定性。
需要完成的稳定工作越少（这也是开发过程的开销，应该被消除），代码库可以更频繁地推送到任何给定的环境。在许多公司中，部署可能是一个非常艰苦的过程。甚至是为期一周的全员操作。这是昂贵的并且没有商业价值。通过采用良好的工作项定义、有效的自动化测试和持续集成，团队可以自动将代码库交付到任何给定环境。
持续部署被描述为持续交付之后合乎逻辑的下一步：只要产品通过 QA，就自动将产品部署到生产中！
在商业环境中你很少会看到这种情况发生，遇到这种情况是相当愉快的。如果代码库可以自动测试并自动部署到任何给定的环境，那么，生产环境就像任何其他环境一样。因此，如果团队已经建立到这一点，那么通过始终能够将更新部署到生产环境，就有可能为业务带来重大价值。
缺陷修复更快地发送给客户，新功能更快地进入市场，新想法以较小的增量针对市场进行测试，以允许重新定向优先级等。
例如，假设一家公司对其基于软件的产品或服务的新功能有一个宏大的想法。他们已经进行了一些研究，他们了解市场，并且他们相信这个想法将带来强劲的新收入。现在考虑提供该功能的两个选项：
- 花几个月的时间在一个一次性的分支中开发整个事情。花数周时间将其重新集成到主代码库中。花几天时间测试它。花一天时间部署它。然后才开始跟踪生产系统中的实际收入。
- 一次一个地实现该功能的一小部分。每周发布一个新的片段。每周获得更多关于实际收入的数据。
在第一种情况下，如果该功能没有达到预期的市场效果，那么很多钱就会浪费在客户实际上并不想要的东西上。在第二种情况下，客户不想要它的事实被确定得非常早，剩下的工作没有优先级。
最终，这些“连续的事情”都是为了消除开发过程的开销。如果一家公司的收入线是一项特定的服务产品，那么理想情况下，他们的所有成本都应该用于该产品。开发流程开销（合并代码、合并后重新测试相同的功能、手动部署任务等）实际上并没有增加服务的价值，因此这些概念试图从流程中消除这些成本。
于 2015-02-19T14:11:43.640 回答
24
一张图可以代替很多词：
享受！:-)
#我已经更新了正确的图像...
于 2017-06-28T09:02:01.647 回答
6
持续集成、持续交付和持续部署之间的区别
于 2017-09-19T09:58:08.993 回答
4
我认为我们过度分析了“连续”的一组词，并且可能会使它们变得复杂。在这种情况下，连续意味着自动化。对于“连续”附加的其他词，请使用英语作为您的翻译指南，请不要试图使事情复杂化！
在“持续构建”中，我们自动将我们的应用程序构建（写入/编译/链接/等）为特定平台/容器/运行时/等可执行的东西。
“持续集成”意味着您的新功能在与另一个实体交互时测试并按预期执行。显然，在集成发生之前，必须进行构建，并且还将使用彻底的测试来验证集成。因此，在“持续集成”中，人们使用自动化来为现有的功能增加价值，这种方式不会对现有功能产生负面影响，而是与其很好地集成，从而为整体增加感知价值。
仅通过英语定义，集成意味着事物和谐地运转，因此在代码对话中，我的 add 编译、链接、测试并在整体内完美运行。如果最终产品失败了，您不会将其称为集成的东西，对吗？！
在我们的上下文中，“持续部署”是“持续交付”的同义词，因为最终我们已经为客户提供了功能。但是，通过过度分析这一点，我可以说部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了。我们部署了代码，但由于我们没有有效地与利益相关者沟通，我们未能从业务角度交付！我们部署了部队，但我们还没有将承诺的水和食物送到附近的城镇。
如果我要加上“持续过渡”这个词，它会有它自己的优点吗？毕竟，也许它更适合描述代码在环境中的移动，因为它比部署或交付更具有“从/到”的含义，部署或交付可能只意味着一个位置，永远！如果我们不运用常识，这就是我们得到的。
总之，这是很简单的描述（做起来有点……复杂！），只要使用常识，英语就可以了。
于 2016-10-21T08:52:32.410 回答
3
持续集成：不断将开发工作与主分支合并的做法，以便尽可能频繁地测试代码以尽早发现问题。
持续交付：一旦代码准备好交付，就向环境持续交付代码。这可能是分期或生产。这个想法是将产品交付给用户群，该用户群可以是 QA 或客户进行审查和检查。
持续集成阶段的单元测试无法捕捉到所有的错误和业务逻辑，尤其是设计问题，这就是我们需要 QA 或用于测试的暂存环境的原因。
持续部署：代码准备就绪后立即部署或发布。持续部署需要持续集成和持续交付，否则代码质量将无法在发布中得到保证。
持续部署~~持续集成+持续交付
于 2018-01-27T15:59:18.160 回答
2
持续集成
- 自动化（构建签到+单元测试）
持续交付
- 持续集成
- 自动化（部署到测试环境+负载测试+集成测试）
- 手册（部署到生产）
持续部署
- 持续交付但自动化（部署到生产）
CI/CD 是一段旅程。不是目的地。
这些阶段是建议。您可以根据业务需求调整阶段。对于多种类型的测试、安全性和性能，可以重复某些阶段。根据项目的复杂性和团队的结构，某些阶段可以在不同级别重复多次。例如，一个团队的最终产品可能成为下一个团队项目的依赖项。这意味着第一个团队的最终产品随后作为工件在下一个团队的项目中上演。
脚注：
于 2019-06-15T08:01:49.397 回答
2
什么是持续集成 持续集成是自动化构建和自动化测试的过程或开发实践，即开发人员需要将其代码多次提交到共享存储库中，每个集成都通过自动化构建和测试进行验证。
如果构建失败/成功，则会通知开发人员，然后他可以采取相关措施。
什么是持续交付 持续交付是我们在任何时候保持我们的代码可部署的实践，这些代码已经通过了所有测试并且具有将代码推送到生产但尚未部署的所有必需配置。
什么是持续部署 在 CI 的帮助下，我们为我们的应用程序创建了构建，并准备好推送到生产环境。在这一步中，我们的构建已经准备就绪，我们可以使用 CD 将我们的应用程序直接部署到 QA 环境中，如果一切顺利，我们可以将相同的构建部署到生产环境中。
所以基本上，持续部署比持续交付更进一步。通过这种做法，通过生产管道所有阶段的每个更改都会发布给您的客户。
持续部署是配置管理和容器化的结合。
配置管理： CM 是关于维护服务器的配置，这将与应用程序要求兼容。
容器化：容器化是一组费用，它将在整个环境中保持一致性。
于 2020-01-22T09:29:14.287 回答
1
DevOps 是 3C 的组合——持续、沟通、协作，这导致了各个行业的主要关注点。
在物联网连接的设备世界中，产品所有者、Web、移动和 QA 等多个 scrum 功能以敏捷的方式在 scrum 循环中工作，以将产品交付给最终客户。
持续集成：多个 scrum 功能在多个端点同时工作
持续交付：通过集成和部署，将产品交付给多个客户同时处理。
持续部署：多个产品在多个平台上部署到多个客户。
观看此视频以了解 DevOps 如何实现物联网互联世界：https ://youtu.be/nAfZt2t4HqA
于 2017-02-10T06:02:06.590 回答
1
根据我在持续交付和 DevOps课程中与 Alex Cowan 学到的知识，CI 和 CD 是产品管道的一部分，包括从观察到发布产品的时间。
从观察到设计，目标是获得高质量的可测试想法。这部分过程被认为是持续设计。
之后会发生什么，当我们从代码开始时，它被认为是一种持续交付能力，其目的是非常快速地执行想法并发布给客户（您可以阅读 Jez Humble 的书持续交付：通过构建、测试进行可靠的软件发布，和部署自动化了解更多详细信息）。以下管道解释了持续集成 (CI) 和持续交付 (CD) 包含哪些步骤。
持续集成，正如Mattias Petter Johansson 解释的那样，
是指软件团队习惯于每天进行多次合并，并且他们有一个自动验证系统来检查这些合并是否存在问题。
（您可以观看以下两个视频，了解使用 CircleCI -开始使用 CircleCI - 持续集成 P2和在拉取请求上运行 CircleCI的更实用的概述）。
可以指定 CI/CD 管道如下，从新代码到发布的产品。
前三个步骤与测试有关，扩展了正在测试的范围。
另一方面，持续部署是自动处理部署。因此，任何通过自动化测试阶段的代码提交都会自动发布到生产环境中。
注意：这不一定是您的管道应有的样子，但它们可以作为参考。
于 2020-04-11T09:54:15.227 回答
0
让我们保持简短：
CI： 一种软件开发实践，团队成员至少每天集成他们的工作。每个集成都通过自动构建（包括测试）进行验证，以尽可能快地检测错误。 CD： CD Builds on CI，您可以在其中构建软件，使软件可以随时发布到生产环境中。
于 2020-06-15T07:01:04.297 回答