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

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.

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

让我们长话短说:

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

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

享受吧!：-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我认为我们过度分析了“连续”一组词，可能把它复杂化了一点。在这种情况下，连续意味着自动化。对于“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.

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

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

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

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

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