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

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

持续集成:多个scrum特性在多个端点同时工作 持续交付:通过集成和部署，同时向多个客户交付产品。 持续部署:在多个平台上将多个产品部署到多个客户。

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

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

享受吧!：-)

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

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

根据我和Alex Cowan在持续交付和开发运维课程中所学到的，CI和CD是产品管道的一部分，包括从观察到发布产品的时间。

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

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

持续集成，正如Mattias Petter Johansson解释的那样，

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

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

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

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

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

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

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

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

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

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

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

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

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

配置管理:CM主要是维护与应用程序需求兼容的服务器配置。

容器化:容器化是一组将在整个环境中保持一致性的费用。

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

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

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

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

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

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

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

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

The less stabilization work that needs to be done (which, again, is development process overhead and should be eliminated), the more often that codebase can be pushed to any given environment. In a lot of companies a deployment can be a pretty grueling process. Even a week-long all-hands-on-deck operation. This is expensive and produces no business value. By employing good work item definitions, effective automated testing, and continuous integration a team can be in a position to automate the codebase's delivery to any given environment.

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

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

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

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

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

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

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