持续流程对于DevOps和敏捷开发至关重要。这些方法使团队能够以极快的速度和准确性发布功能、更新和修复。由于某些相似性，不同连续过程之间的界限往往是模糊的。本文指出了持续集成（CI）、持续交付（CD）和持续部署（CD）之间的区别。继续阅读以了解有关这些做法的更多信息，看看哪一种最适合您的团队。

持续交付与持续部署与持续集成：有什么区别

以下是这三种做法的简要总结：

持续集成、交付和部署以多种方式重叠。CI是持续交付和持续部署的重要组成部分。持续部署涵盖与持续交付相同的流程，只是发布是自动发生的。

下表比较了持续交付、持续部署和持续集成：

持续集成

持续交付

持续部署

具有快速反馈的全自动集成、构建和测试流程

CI+带有手动触发的自动软件发布流程

CI+CD+全自动部署到生产

在开发人员签入后立即发生

交付一直进行，直到团队认为代码已准备好交付

所有代码自动直接进入生产阶段

使用单元和业务逻辑测试

可以使用任何测试策略

需要CI服务器来监控存储库

需要强大的CI基础

需要强大的CI和良好的测试文化

团队必须为每个新功能或错误修复编写自动化测试

测试套件必须覆盖足够多的代码库

测试套件的质量决定了发布的质量

开发人员尽可能频繁地合并他们的更改（至少每天一次）

团队可以选择使用功能标志

功能标志是该过程的重要组成部分

集成、交付和部署并不是相互排斥的。单个管道可以包含所有三种方法。许多CI/CD工具可以帮助您设置和运行高效的管道。

持续集成(CI)

持续集成涉及一系列自动步骤，这些步骤集成来自多个源的代码、创建构建和测试软件。

CI还可能包括将新设计概念集成到DevOps管道中。

CI的工作原理

CI需要使用持续集成服务器，例如Jenkins或Bamboo。CI服务器自动测试不同开发人员编写的代码。每当一组代码或构建通过本地单元测试时，自动部署会将软件带到暂存环境。在那里，更新会经过进一步的测试，例如负载或手动探索性测试。然后代码合并到主代码库中。

持续集成的好处

持续集成要求

持续集成最佳实践

持续交付(CD)

持续交付依赖于人类来决定向用户发布什么以及何时发布。部署速率取决于业务需求。

CD的工作原理

开发人员通过CI流程添加改进、功能和错误修复。手动提交后，CD工具通过自动部署管道获取代码。持续交付通常具有类似生产的暂存区域，但在最终版本中存在时间滞后。延迟允许在投入生产之前审查并手动接受代码中的更改。

持续交付的好处

持续交付要求

持续交付最佳实践

持续部署(CD)

在持续部署中，每个代码更改都经过一个自动化管道，应用程序的工作版本会自动发布到生产环境。与持续交付不同，持续部署没有发布审批周期。由于没有手动触发器，此设置依赖于自动测试以防止错误到达最终用户。持续部署的目标是实现几乎不断发布的更新。一旦开发人员编写和测试代码，用户就会收到更新。

持续部署的工作原理

持续交付遵循按需模型，而持续部署则自动推动每个部署。在合并到主线分支之前，所有测试都在类生产环境中进行。持续部署不需要用于手动审查代码更改的暂存区。自动化测试发生在开发过程的早期，并贯穿于整个发布阶段。持续交付和部署之间的差异将继续扩大，因为像Docker这样的工具可以很容易地自动化应用程序部署。

持续部署的好处

持续部署要求

持续部署最佳实践

哪种持续练习适合您？

在您考虑哪种做法最适合您之前，请了解您的团队必须拥有能够处理CI/CD的DevOps文化。您还应该考虑潜在的限制，例如合规法律。法规可能会阻止组织使用持续部署。

如果您的团队能够支持持续流程，请问自己以下问题：

如果您对上述问题的回答是肯定的，那么持续部署可能是一个值得的选择。考虑自动化您的整个软件交付，从代码提交到生产。如果您对某些或所有问题的回答为“否”，那么您最好从持续集成和持续交付开始。考虑自动创建生产就绪代码，但需要手动批准部署。随着时间的推移，您的团队可以继续朝着软件交付过程的持续部署和完全自动化发展。

做出明智的商业选择

持续的流程有助于尽可能快地构建、测试和发布软件，同时尽可能减少错误。某些方法在某些情况下比在其他情况下效果更好。团队必须了解持续集成、交付和部署之间的区别，才能充分利用这些实践。现在您已了解每个流程提供的内容，请选择符合您需求的选项，并轻松过渡到DevOps。