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

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

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

实现持续交付的步骤:

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

Continuous Build: automated build on every check-in, which is the first step, but does nothing to prove functional integration of new code. Continuous Integration (CI): automated build and execution of at least unit tests to prove integration of new code with existing code, but preferably integration tests (end-to-end). Continuous Deployment (CD): automated deployment when code passes CI at least into a test environment, preferably into higher environments when quality is proven either via CI or by marking a lower environment as PASSED after manual testing. I.E., testing may be manual in some cases, but promoting to next environment is automatic. Continuous Delivery: automated publication and release of the system into production. This is CD into production plus any other configuration changes like setup for A/B testing, notification to users of new features, notifying support of new version and change notes, etc.

EDIT: I would like to point out that there's a difference between the concept of "continuous delivery" as referenced in the first principle of the Agile Manifesto (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). The practice of Continuous Delivery (CD) by agile teams has emerged in the many years since the Agile Manifesto was written in 2001. This agile practice directly addresses the principle, although they are different things and apparently easily confused.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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，就自动将其部署到生产环境!

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

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

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

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

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

---

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

持续集成

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

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

这与你分配给开发者的任务大小有关;如果一项任务估计需要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提交到管道确认我们有一个有效的候选版本，这个过程是自动化的。

持续集成

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

持续交付

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

持续部署

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

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.

补充说明:

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

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

简而言之:

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

持续交付——即持续集成+通过“点击一个按钮”将应用程序部署到生产环境(通常是发布给客户，但按需发布)。

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