原文: https://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/
Timothy Fitz 关于持续部署的博客文章(中文版)在我和 Dave 出版《持续交付》一书之前一年多就发表了。 为什么我们选择了不同的名字呢？ 是实际上有区别还是我们心血来潮？
我们决定把这本书叫做《持续交付》有几个原因。首先，有一个有点学究的事实是：部署并不意味着发布。就像我们在书中说的那样，你可以持续部署到 UAT 环境——这不是什么太大的问题。持续部署特别之处在于每次变更都要通过自动化测试（或者通过可选的 QA 门禁）到生产环境。持续部署是一个发布每个良好构建给用户的实践——更精确的名称可能是“持续发布”。
尽管持续部署意味着持续交付，但反之并不成立。持续交付是把发布计划的决策权交给业务，而不是 IT。实施持续交付意味着确保您的软件在其整个生命周期中始终处于生产就绪状态 - 任何一次构建都可能在几秒钟或几分钟内使用完全自动化的过程发布给用户。
这又依赖于构建、测试和部署过程的全面自动化，以及参与交付的每个人（开发人员、测试人员、DBA、系统管理员、用户和业务）之间的出色协作。
在持续交付的世界中，当开发人员把特性交给测试人员测试时，或者当功能“QA 测试通过”时，他们并没有真正“完成”这个特性。直到特性在生产环境中真正工作时才算“完成”。这意味着不再有测试或部署阶段，即使在一个 sprint 中（如果您使用 Scrum）。 如果你正在使用看板并且想要进行持续交付，直到故事发布给用户之前，这个故事都没有发挥作用。
然而，向用户发布每次成功的构建并不总是有意义的。特别是当软件变更和硬件变更之间存在耦合时，这对于嵌入式产品通常是不可能的。 在 COTS 的世界中，有充分的营销和售后支持理由说明为什么你不想随时时间使用多个“已发布”版本的软件（尽管你仍然可以做常规的“开发人员”或“早期访问”的版本，如 Eclipse 和 Omni Group 所做的那样）。可能还有其他好的动因——但重要的是它们必须是业务驱动。
那么你什么时候可以说你在做持续交付呢？ 我想说的是，如果你认为这是为客户提供价值的最佳方式，那么你可以切换到持续部署。特别是，如果你无法保证向用户每次发布一个成功的构建。那么“完成”一个故事意味着什么？ 我认为至少必须满足以下条件：
- 你已经针对包含故事的构建运行了整个测试套件。 这些测试套件验证了故事预期交付的业务价值，并且在开发过程中没有引入任何回归。为了提高效率，这意味着在单元、组件和验收级别进行全面的自动化测试。
- 该故事已在类生产环境中向客户展示。类生产环境意味着在合理的范围内与生产环境相同。 即使你要部署到一个庞大的集群，你也可以使用蓝绿部署之类的技术在生产环境中并行运行不同版本的应用程序，而不会影响用户。
- 部署到生产环境没有障碍。 换句话说，如果你决定，只需按一下按钮，你就可以使用完全自动化的流程将构建部署给用户。 尤其是你还测试了它是否满足其非功能特性，例如容量、可用性和安全性。 如果您正在使用 SOA，或者你的应用程序和其他系统之间存在依赖关系，要确保其中没有集成问题。
（完）
