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

或者一天几次以上。基本上，任何离散任务完成的频率都是相同的。例如，考虑一个开发团队在开发一个业务应用程序。在许多环境中，可能会发生以下情况:

• 一两个开发人员将本地更改保留几天，因为“它还没有准备好”。
• 一两个开发人员在源代码控制中创建分支，这样他们就可以处理他们的特性。“不被别人的改变所困扰”。

这可能会导致问题。糟糕的代码/任务组织导致分支，分支导致合并，合并……导致痛苦。持续集成作为一种实践，通过鼓励每个人从相同的共享源工作来解决这个问题。单独的工作项应该足够分散，以便在很短的时间内(最多几个小时)完成。

基本上总的思想是在少量的工作中集成少量的变更。集成一个大的变更是不成比例的大量工作。如果以恒定的小步骤完成，那么积分功的总和会更小。这允许开发人员将更多的时间花在业务可见的特性上，而不是开发过程开销。

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

这遵循了离散的、定义良好的工作项的相同思想。如果有一个单一的主代码库，它只会根据完整的、经过测试的、已知的工作特性进行少量调整，那么该代码库总是稳定的。自动化测试在这里是能够证明按下按钮的稳定性的关键。

需要做的稳定工作(同样，这是开发过程开销，应该消除)越少，代码库就越容易被推到任何给定的环境中。在许多公司中，部署是一个相当累人的过程。甚至是长达一周的全员行动。这是昂贵的，没有产生任何商业价值。通过采用良好的工作项定义、有效的自动化测试和持续集成，团队可以处于将代码库自动交付到任何给定环境的位置。

持续部署被描述为持续交付之后的逻辑下一步:只要产品通过QA，就自动将其部署到生产环境!

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

缺陷修复更快地发送给客户，新特性更快地到达市场，新想法以较小的增量针对市场进行测试，以允许优先级的重定向，等等。

例如，假设一家公司对其基于软件的产品或服务的新功能有一个很大的想法。他们做了一些研究，他们了解市场，他们相信这个想法会带来新的收入来源。现在考虑交付该功能的两个选项:

1. 花几个月的时间在一个分支中开发整个东西。花费数周时间将其集成回主代码库。花几天时间进行测试。花一天时间来部署它。并且只有然后开始跟踪生产系统中的实际收入。
2. 实现功能的一小部分，一次一个。每周发布一篇新文章。每周获得更多的实际收入数据。

在第一种情况下，如果功能没有预期的市场效果，那么很多的钱就浪费在客户实际上不想要的东西上。在第二种情况下，客户不需要它的事实在更早的时候就被确定了，其余的工作也被降低了优先级。

最终，这些“持续的事情”都是关于消除开发过程开销。如果一家公司的收入线是一项特定的服务，那么理想情况下，他们所有的成本都应该用于该服务。开发过程开销(合并代码、合并后重新测试相同的功能、手动部署任务等)实际上对服务的价值没有贡献，因此这些概念试图从流程中去除这些成本。

持续集成

我同意贵校的定义。持续集成是一种策略，用于开发人员如何持续地将代码集成到主线中——而不是频繁地集成。

您可能会声称它只是版本控制系统中的分支策略。

这与你分配给开发者的任务大小有关;如果一项任务估计需要4-5个工作日，那么开发人员将没有动力在接下来的4-5天内交付任何东西，因为他还没有完成任何事情。

所以大小很重要:

small task = continuous integration
big task   = frequent integration

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

持续交付

连续交付中基本上有三个学校:

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

这一学派研究了艾迪生-卫斯理“马丁·福勒”;签名系列，并假设由于2007年的版本被称为“连续Integration"，而2011年的版本被称为“连续Delivery"，它们可能是与连续某物有关的相同概念的第1+2卷。

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

这所学校的观点是，持续交付是关于能够支持敏捷运动中的原则，不仅仅是概念性的想法或意向书，而是真实的——在现实生活中。

在敏捷宣言的第一个原则中，术语“连续交付”;实际上是第一次使用:

我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。

这所学校声称“持续交付”;是一个范例，它包含了实现done的定义;自动验证所需的一切。

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

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

第三种学派主张持续部署和持续交付可以互换使用来表示相同的东西。

当某些东西在开发人员手中准备就绪时，它会立即交付给最终用户，这在大多数情况下意味着应该将其部署到生产环境中。因此“Deploy"和“;Deliver"意思相同。

加入哪所学校

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

我个人主张这样一种理解:持续交付与实现对敏捷运动所陈述的思想和概念的现实支持有关。所以我加入了一个学派，他们认为这个术语包含了一个完整的范式——比如“发展”。

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

持续部署

对持续部署的关注主要与以下领域相关:终端用户对软件更新的访问依赖于某些集中式数据源的更新，而这些集中式数据源并不总是容易更新，因为它是单一的，或者本质上具有(太高)一致性(web、SOA、数据库等)。

对于许多没有集中式信息源(设备、消费产品、客户端安装等)或集中式信息源易于更新的软件领域(应用商店工件管理系统、开源存储库等)，几乎没有人大肆宣传持续部署这个术语。他们只是部署;这不是什么大不了的事，也不是什么需要特别关注的痛苦。

事实上，持续部署并不是每个人都感兴趣的东西，这也是学校声称“交付”的一个论点;和“;deploy"同义词都错了吗?因为持续交付实际上对每个人都有很好的意义——即使你是在设备中做嵌入式软件或为框架发布开源插件。

你们大学对持续部署的定义是持续交付的自然下一步，隐含地假设每个经过QA的交付都应该立即提供给最终用户，这更接近于我的部落用来描述术语“持续发布”的定义，而“持续发布”反过来也是一个对每个人都没有一般意义的概念。

发布可能是一件非常具有战略意义或政治性的事情，没有理由假设每个人都想一直这样做(除非他们是在线书店或流媒体服务类型的公司)。然而，那些不盲目地一直发布所有东西的公司可能有很多原因为什么他们想成为部署大师，所以他们也做持续部署。不是发布到生产，而是发布候选到类似生产环境。

我再次相信你们的大学搞错了。他们错把“持续部署”;“持续释放”。

持续部署就是持续地将开发过程的结果转移到类似生产环境的规程，在这种环境中可以全面执行功能测试。

持续交付故事线

在这幅画中，一切都活了起来:

持续集成过程是状态转换图中的前两个操作。如果成功，将启动实现完成的定义. xml的持续交付管道。部署只是这个管道中必须持续执行的众多操作之一。理想情况下，从开发人员向VCS提交到管道确认我们有一个有效的候选版本，这个过程是自动化的。

问题和答案都不符合我简单的思考方式。我是一名顾问，并与许多开发团队和DevOps人员同步了这些定义，但我很好奇它如何与整个行业相匹配:

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

非连续(一切手工)0% ----> 100%持续交付价值(一切自动化)

实现持续交付的步骤:

零。当开发人员签入代码时，没有什么是自动的……如果他们在签入之前已经编译、运行或执行了任何测试，那么您就很幸运了。

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

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

3. 持续部署(CD):当代码至少通过CI进入测试环境时自动部署，当质量通过CI或通过手动测试后将较低的环境标记为PASSED时，最好是进入较高的环境。例如，在某些情况下，测试可能是手动的，但升级到下一个环境是自动的。

4. 持续交付:系统自动发布并发布到生产环境中。这是CD到产品加上任何其他配置更改，如A/B测试的设置，通知用户的新功能，通知新版本的支持和更改说明，等等。

编辑:我想指出的是，在敏捷宣言(http://agilemanifesto.org/principles.html)的第一原则中提到的“持续交付”概念和持续交付实践之间存在差异，这似乎是由问题的上下文所引用的。持续交付的原则是努力减少库存浪费，正如精益思想(http://www.miconleansixsigma.com/8-wastes.html)所描述的那样。自2001年敏捷宣言撰写以来，敏捷团队的持续交付实践已经出现了很多年。这种敏捷实践直接解决了这个原则，尽管它们是不同的东西，而且显然很容易混淆。

我认为我们对“连续”这个词的分析过度了，而且可能有点复杂了。一套词。在这种情况下，连续意味着自动化。对于“连续的”后面的其他单词;用英语作为翻译指南，不要试图把事情复杂化!

在“连续建造”中;我们自动地构建(写入/编译/链接/等等)我们的应用程序，使其在特定的平台/容器/运行时等可执行。

“连续integration"意味着您的新功能在与另一个实体交互时按预期进行测试和执行。显然，在进行集成之前，必须进行构建，并且还将使用彻底的测试来验证集成。因此，在“持续集成”中;人们使用自动化来为现有的功能桶增加价值，这种方式不会消极地破坏现有的功能，而是与它很好地集成，为整体增加可感知的价值。

从简单的英语定义来看，集成意味着事物和谐地运行，在代码对话中，我的add在整体中编译、链接、测试和运行完美无缺。如果一个东西不能得到最终产品你就不能称之为集成，对吧!

在我们的语境中，“持续部署”;是“连续交货”的同义词;因为在一天结束的时候，我们为我们的客户提供了功能。然而，通过过度分析，我可以认为部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了。我们部署了代码，但因为我们没有有效地与涉众沟通，所以我们未能从业务角度交付!我们部署了军队，但我们还没有把承诺的水和食物送到附近的城镇。

如果我加上“连续过渡”会怎么样?术语，它有自己的优点吗?毕竟，也许它更适合描述代码在环境中的移动，因为它具有“从/到”的含义。比部署或交付更重要的是，这可能意味着只有一个位置，永远!如果我们不运用常识，这就是我们得到的结果。

总之，这是很简单的描述(做起来有点…复杂!)，只要使用常识，英语，你就会好起来的。

我认为亚马逊的定义是直接和简单的理解。

持续交付是一种软件开发方法，其中发布过程是自动化的。每个软件变更都会自动构建、测试并部署到生产环境中。在最终发布到生产环境之前，由一个人、一个自动化测试或一个业务规则决定何时进行最后的发布。尽管每个成功的软件变更都可以立即发布到持续交付的生产环境中，但并不是所有的变更都需要立即发布。

持续集成是一种软件开发实践，其中团队成员使用版本控制系统并频繁地将他们的工作集成到相同的位置，例如主分支。为了尽可能快地检测任何集成错误，每个更改都通过测试和其他验证来构建和验证。持续集成专注于自动构建和测试代码，与持续交付相比，持续交付将整个软件发布过程自动化，直到生产。”

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

DevOps是3C的组合——连续， 沟通， 协作，这导致了各个行业的主要关注。

在物联网连接设备的世界中，产品所有者、web、移动和QA等多种scrum功能以敏捷的方式在scrum周期中工作，将产品交付给最终客户。

多个scrum特性同时在多个端点工作

持续交付:通过集成和部署，同时向多个客户交付产品。

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

观看此视频，了解DevOps如何实现物联网连接的世界:https://youtu.be/nAfZt2t4HqA

一个图表可以代替很多单词:

享受吧!: -)

# 我已经更新了正确的图片…

Atlassian发布了一个关于持续集成、持续交付、持续部署的很好的解释。

简而言之:

持续集成 - is 每当新的提交被推入分支时，自动构建和测试应用程序

通过“点击按钮”将应用程序部署到生产(通常是发布给客户，但根据需求)。

持续部署 - is 连续交付但没有人为干预(向客户发布正在进行中)。

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

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

持续交付:当代码准备好发布时，持续向环境交付代码。这可以是分期或生产。其理念是将产品交付给用户群，用户群可以是QA或客户，以便进行审查和检查。

持续集成阶段的单元测试不能捕捉到所有的错误和业务逻辑，特别是设计问题，这就是为什么我们需要QA或测试环境。

持续部署:一旦代码准备好，就立即进行部署或发布。持续部署需要持续集成和持续交付，否则在发布版中代码质量将得不到保证。

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

持续集成

• 自动化(签入+单元测试的构建)

持续交付

• 持续集成
• 自动化(部署到测试环境+负载测试+集成测试)
• 手动(从部署到生产)

持续部署

• 持续交付但自动化(部署到生产)

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

这些阶段是建议。你可以根据你的 业务需求。某些阶段可以重复用于多种类型的 测试、安全性和性能。取决于的复杂度 你的项目和你的团队结构，有些阶段可以 在不同的水平重复几次。例如，结束 一个团队的产品可能成为下一个团队项目的依赖项 团队。这意味着第一个团队的最终产品是后续的

补充说明:

连续练习 集成与持续 AWS交付

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

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

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

什么是持续交付 持续交付是一种实践，在这种实践中，我们保持我们的代码在任何通过了所有测试的地方都是可部署的，并且拥有将代码推入生产环境所需的所有配置，但还没有部署

什么是持续部署 在CI的帮助下，我们已经为我们的应用程序创建了构建，并准备将其推向生产环境。在这一步中，我们的构建已经准备好了，通过CD，我们可以直接将应用部署到QA环境中，如果一切顺利，我们可以将相同的构建部署到生产环境中

所以基本上，持续部署比持续交付更进一步。通过这种实践，通过您的生产管道的所有阶段的每个变更都被发布给您的客户。

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

配置管理: CM是关于维护服务器的配置，这将是兼容的应用程序的需求。

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

Img来源:https://www.atlassian.com/

从我和Alex Cowan在课程中所学到的连续交付&DevOps, CI和CD是产品管道的一部分，包括从观察到发布产品的时间。

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

之后发生的事情，当我们从代码开始，它被认为是一个持续交付能力，其目标是执行想法并非常快速地发布给客户(你可以阅读Jez Humble的书持续交付:通过构建、测试和部署自动化的可靠软件发布了解更多细节)。下面的管道说明持续集成(CI)和持续交付(CD)由哪些步骤组成。

持续集成，作为Mattias Petter Johansson解释，

是指软件团队有每天进行多次合并的习惯 他们有一个自动验证系统来检查这些

(您可以观看以下两个视频，以获得使用CircleCI - 开始使用CircleCI -连续集成P2和在Pull Request上运行CircleCI的更实际的概述)。

可以像下面这样指定CI/CD管道，从新代码到发布的产品。

前三个步骤与测试有关，扩展被测试对象的边界。

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

请注意:这并不一定是你的管道应该是什么样子，但它们可以作为参考。

让我们长话短说:

< >强置信区间: 一种软件开发实践，团队成员至少每天集成他们的工作。每个集成都通过自动构建(包括测试)进行验证，以尽可能快地检测错误。 CD: CD构建在CI之上，在CI中，您以这样一种方式构建软件，软件可以在任何时候发布到生产中