让我们长话短说:

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

问题和答案都不符合我简单的思考方式。我是一名顾问，并与许多开发团队和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.

持续集成

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

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

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

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

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

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

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

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

持续集成:是开发人员尽可能频繁地将对代码库的更改合并到主分支的实践。通过创建构建，然后对构建运行自动化测试来验证这些更改。如果这些测试没有通过，更改就不会合并，开发人员就会避免可能发生的集成挑战。

Continuous Delivery : is an extension of CI since it enables automation to deploy all the code changes to an environment (dev, qa, stage, prod, etc) after the changes have been merged. The artifact may be built as part of CI or as part of this process since the source of truth (your repository) is reliable given your CI process. In simple terms, this means that there is an automated release process on top of the automated testing process and that developers can deploy their changes at any time by simply clicking a button or at the completion of CI.

持续部署:比持续交付更进一步。在这里，在管道的每个阶段通过验证步骤的所有更改都将发布到生产环境中。这个过程是完全自动化的，只有一个失败的验证步骤才能阻止将更改推到生产环境中。

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

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

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

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

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

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

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

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

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

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