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

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

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

Continuous integration is a software development practice where members of a team use a version control system and integrate their work frequently to the same location, such as a master branch. Each change is built and verified by tests and other verifications in order to detect any integration errors as quickly as possible. Continuous integration is focused on automatically building and testing code, as compared to continuous delivery, which automates the entire software release process up to production."

请访问http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

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

享受吧!：-)

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

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

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

"Continuous integration" means that your new functionality tests and performs as intended when interacting with another entity. Obviously, before integration takes place, the build must happen and thorough testing would also be used to validate the integration. So, in "continuous integration" one uses automation to add value to an existing bucket of functionality in a way that doesn't negatively disrupt the existing functionality but rather integrates nicely with it, adding a perceived value to the whole.

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

In our context "Continuous deployment" is synonymous with "continuos delivery" since at the end of the day we've provided functionality to our customers. However, by overanalyzing this, I could argue that deploy is a subset of delivery because deploying something doesn't necessarily mean that we delivered. We deployed the code but because we haven't effectively communicated to our stakeholders, we failed to deliver from a business perspective! We deployed the troops but we haven't delivered the promised water and food to the nearby town.

如果我加上“连续过渡”一词，它会有自己的优点吗?毕竟，也许它更适合描述代码在环境中的移动，因为它具有“从/到”的内涵，而不是部署或交付，后者可能只意味着永久地在一个位置!如果我们不运用常识，这就是我们得到的结果。

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

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

持续集成

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

持续交付

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

持续部署

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

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