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

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.

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

问题和答案都不符合我简单的思考方式。我是一名顾问，并与许多开发团队和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提交到管道确认我们有一个有效的候选版本，这个过程是自动化的。

持续集成

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

持续交付

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

持续部署

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

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交付

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

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.

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

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

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

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

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

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

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

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

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

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

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