持续交付与持续部署以及持续集成的区别

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

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

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

• 持续集成 (CI)：一旦开发人员签入，CI 就会执行自动集成、构建和代码测试。
• 持续交付 (CD)：使用 CD，在集成、构建和测试之后会发生自动发布过程。
• 持续部署 (CD)：通过生产管道的每个代码更改都会启动部署，无需人工干预。

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

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

持续集成	持续交付	持续部署
具有快速反馈的全自动集成、构建和测试流程	CI + 带有手动触发的自动软件发布流程	CI + CD + 全自动部署到生产
在开发人员签入后立即发生	交付一直进行，直到团队认为代码已准备好交付	所有代码自动直接进入生产阶段
使用单元测试	使用单元和业务逻辑测试	可以使用任何测试策略
需要 CI 服务器来监控存储库	需要强大的 CI 基础	需要强大的 CI 和良好的测试文化
团队必须为每个新功能或错误修复编写自动化测试	测试套件必须覆盖足够多的代码库	测试套件的质量决定了发布的质量
开发人员尽可能频繁地合并他们的更改（至少每天一次）	团队可以选择使用功能标志	功能标志是该过程的重要组成部分

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

持续集成 (CI)

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

CI的主要目标是：

• 快速发布新更新
• 使独立团队能够在同一个项目上进行协作
• 在潜在问题造成损害之前识别并修复它们

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

CI 的工作原理

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

持续集成的好处

• 在几分钟内构建、集成和测试新的代码段
• 开发人员在不影响代码稳定性的情况下独立开发功能
• 部署更快、更可预测
• 更少的生产错误
• 出现问题及时反馈
• 消除发布日的集成挑战
• QA 团队在后期手动测试上花费的时间更少
• 鼓励代码透明度和代码协作
• 更少的上下文切换

持续集成要求

• 监控中央存储库的 CI 服务器（在本地或云端设置）
• 对每个新的改进、功能或错误修复进行自动化测试

持续集成最佳实践

• 维护代码存储库
• 始终自动化软件构建
• 尽可能快地保持构建
• 进行自我测试构建（持续测试）
• 对基线的提交应该每天发生
• 在生产环境的克隆中运行测试
• 轻松获取最新的可交付成果
• 使最新构建的结果透明

持续交付 (CD)

在 CI 之上，持续交付还在集成和构建阶段之后提供了一个自动化的发布过程。手动触发器控制部署到生产。

CD的主要目标是：

• 准备就绪时交付新功能
• 构建稳定、有弹性的系统
• 确保业务应用程序不间断运行

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

CD 的工作原理

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

持续交付的好处

• 加速发布周期
• 更快的上市时间
• 准备和设置版本的时间更少
• 增加迭代次数可以减少风险、缩短恢复时间并让客户更满意
• 在交付过程的早期发现错误
• 交付更高效、更安全
• 可预测的交付速度
• 更快的用户反馈循环
• 开发人员做更少的手动工作

持续交付要求

• 强大的 CI 基础
• 早期开发阶段的优化
• 涵盖足够代码库的测试套件
• 功能标志，以防止不完整的功能影响生产中的用户

持续交付最佳实践

• 确保有一个强大的 CI 设置支持持续交付流程
• 调整您的软件系统以适应 CD，而不是相反
• 自动化尽可能多的流程
• 使用短而宽的部署管道
• 在开发和生产之间至少有一站
• 以相同的方式部署到所有环境
• 从版本控制驱动更改
• 在管道中包含数据库
• 监控和记录交付管道

持续部署 (CD)

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

持续部署的工作原理

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

持续部署的好处

• 无需人工干预的自动部署触发器
• 将每个新的主线添加部署到最终用户
• 团队发展得更快（发布没有暂停，手动重复性任务更少）
• 小批量代码使发布的风险更低，更容易修复
• 统一的管道集成了团队和流程

持续部署要求

• 一个优秀的测试套件
• 能够跟上部署步伐的文档流程
• 完善的功能标志系统，以支持重大更改的发布

持续部署最佳实践

• 维护一个中央代码存储库
• 尽可能多地自动化构建和部署过程
• 每天承诺基线
• 使用问题跟踪器进行开发任务
• 使用包含问题编号和所有更改描述的版本控制分支

哪种持续练习适合您？

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

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

• 您的团队是否需要在持续集成和交付之间手动触发？
• 您是否能够在未经利益相关者批准的情况下进行部署？
• 您可以让您的用户了解生产变更吗？
• 您对生产错误的响应时间是否很快？
• 您的门控要求是否允许端到端自动化

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

做出明智的商业选择

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