有什么区别：持续集成、持续交付和持续部署。

*从我的博客交叉发布。

DevOps 带来了许多新的目标、实践和术语。由于 DevOps 的技术性，许多术语被人们混淆、误用，甚至错误地定义，因为他们没有理解这些术语的具体区别。在这里，我们将用通俗易懂的语言来解释三个最常见的术语，并尝试提供一个清晰的示例来分别界定这三个术语。

持续集成

持续集成具体指的是将变更集不断合并到可靠来源的过程。通常，这指的是开发人员将更改的代码推送到共享的远程仓库。例如，一个由 12 名开发人员组成的团队可能在 18 个不同的 GiT 分支上工作，每天包含超过 67 次提交。这可是个很大的变更量！在一个工作周内，提交的变更数量很容易超过 300 次。当需要部署新版本时，所有这些变更都必须合并到一个分支中。如果发布版本的压力还不够大，团队还必须确保所有变更能够协同工作。我敢保证，每周 300 多次的变更会导致问题。问题意味着加班，应对来自业务负责人的压力，因为担心发布日期而感到压力，业务负责人不信任你或你的团队能否按时按目标交付。在这种情况下，没有人是赢家。

进入持续集成。以同一组织中的同一支开发团队为例，但无需等到发布日才每天多次合并变更。变更会被持续集成到目标 GiT 分支中，以确保在发生变更时立即处理合并问题（当文件被不同人员以两种方式更改时），而不是在尝试发布时才处理。（这是 DevOps 中“左移”概念的一部分。）发布日到来时，变更早在发布事件发生之前就已经合并并发布，并进行了更正。

持续交付

持续交付，作为一个概念，是从无到有、再到持续集成、最终迈向完全自动化的逻辑演进。为了实现持续交付，需要实施适当的自动化质量保证步骤，例如自动化测试、监控、变更和指标。为什么？因为持续交付意味着对软件的任何更改都始终处于交付状态。只需按下按钮，软件即可部署到生产环境。您必须 100% 地确保一切正常，没有任何问题。

我真的很喜欢来自 https://chadhagen.com/Nonsensical-Infographics的那些无意义的信息图表

我在心理上将持续交付与持续部署区分开来的方式是将其视为一个 UPS 包裹：在付款、加工、测试、处理并准备使用后，包裹就会送到您家门口；而在持续部署中，包裹会被拆包、安装并投入使用。

持续部署

这引出了我们今天的最后一个概念：持续部署。在这三个概念中，我认为它最容易定义和概念化。顾名思义，持续部署就是将软件持续部署到用户（也就是真实的人）可以使用应用程序的地方的过程。

持续部署是自动化领域的圣杯，也是许多企业最难采用的。但在成功实现持续集成后，部署似乎变得轻而易举。那么，为什么交付如此难以接受呢？因为它意味着只需对部署分支进行一次提交即可部署。无需人工干预，无需质量门控，无需变更控制委员会的批准。只要收到变更，就会立即部署。

实施路径示例

作为一名开发者，您正在开发功能 1234。作为工作流程的一部分，您将功能 1234 隐藏在应用程序中的功能标记后面。午餐前和下班后，您会立即推送更改并纠正任何合并冲突。这就是持续集成。

作为组织内部自动化策略的一部分，您必须创建单元测试、集成检查和端到端场景，以便提交能够被允许进入源仓库。如果所有自动化测试都通过，提交就可以应用到源仓库。这就是持续交付。

鉴于上述情况，系统运行稳定，组织认识到快速获取最终用户反馈的价值，并相信工程团队能够严格控制中断，并在出现问题时将影响范围降至最低（从而使组织在竞争中保持领先）。假设所有自动化质量保证和测试指标均已通过，代码更改将立即部署到实际生产环境中。这就是持续部署。

资源

结论

Dev(Chat/Git/Sec/No)Ops 是一个不断变化的领域。各种术语和缩写词很容易让人混淆。我希望这篇文章能帮你理清一些最常用的短语。

这并非易事，但如果你能够内化“每个企业都是软件企业”（Watts S. Humphrey）这一事实，我们就能越早意识到软件工程与其他形式的工程并无二致。我们需要运用相同的原则才能获得相同的回报。更高的可见性、更强大的产品、更灵活的内部机制、更快的速度，以及工匠精神带来的尊重。这使得组织能够追求卓越；谁不想追求卓越呢？

那么您如何看待 DevOps？您是否在组织中实施过 DevOps/CI/CD？您如何看待 DevOps 对组织和市场造成的颠覆？

文章来源：https://dev.to/david_j_eddy/whats-the-difference-continuous-integration-continuous-delivery-and-continuous-deployment-183l