持续流程对于DevOps 和敏捷开发至关重要。这些方法使团队能够以极快的速度和准确性发布功能、更新和修复。然而，由于某些相似性，不同连续过程之间的界限往往是模糊的。
本文指出了持续集成 (CI)、持续交付 (CD) 和持续部署 (CD)之间的区别。请继续阅读以了解有关这些实践的更多信息，并了解哪一种最适合你的团队。
持续交付 vs. 持续部署 vs. 持续集成有什么区别
以下是三种做法的快速总结：
- 持续集成 (CI)：一旦开发人员签入，CI 就会执行自动集成、构建和代码测试。
- 持续交付 (CD)：使用 CD，在集成、构建和测试之后会发生自动发布过程。
- 持续部署 (CD)：通过生产管道的每个代码更改都会启动部署，无需人工干预。
持续集成、交付和部署以多种方式重叠。CI 是持续交付和持续部署的重要组成部分。持续部署涵盖与持续交付相同的流程，只是发布是自动发生的。
持续交付 vs 持续部署 vs 持续集成差异比较表：下表比较了持续交付、持续部署和持续集成：
注意：该表格可水平滚动。
| 持续集成 | 持续交付 | 持续部署 |
| 具有快速反馈的全自动集成、构建和测试流程 | CI + 带有手动触发的自动软件发布过程 | CI + CD + 全自动部署到生产 |
| 在开发人员签入后立即发生 | 交付发生，直到团队认为代码已准备好交付 | 所有代码自动直接进入生产阶段 |
| 使用单元测试 | 使用单元和业务逻辑测试 | 可以使用任何测试策略 |
| 需要 CI 服务器来监控存储库 | 需要强大的 CI 基础 | 需要强大的 CI 和良好的测试文化 |
| 团队必须为每个新功能或错误修复编写自动化测试 | 测试套件必须覆盖足够的代码库 | 测试套件的质量决定了发布的质量 |
| 开发人员尽可能多地合并他们的更改（至少每天一次） | 团队可以选择使用功能标志 | 功能标志是该过程的重要组成部分 |
集成、交付和部署并不相互排斥。单个管道可以包含所有三种方法。许多CI/CD 工具可以帮助你设置和运行高效的管道。
持续集成 (CI)
持续交付 vs 持续部署 vs 持续集成有什么区别？持续集成涉及一系列自动步骤，这些步骤集成来自多个源的代码、创建构建和测试软件。
CI的主要目标是：
- 快速发布新更新
- 使独立团队能够在同一个项目上进行协作
- 在潜在问题造成损害之前识别并修复它们
CI 还可能包括将新设计概念集成到DevOps 管道中。
CI 的工作原理
CI 需要使用持续集成服务器，例如 Jenkins 或 Bamboo。CI 服务器自动测试由不同开发人员编写的代码。
每当一组代码或构建通过本地单元测试时，自动部署会将软件带到临时环境。到达那里后，更新将经过进一步测试，例如负载或手动探索性测试。然后代码合并到主代码库中。
持续集成的好处
- 在几分钟内构建、集成和测试新的代码段
- 开发人员在不影响代码稳定性的情况下独立处理功能
- 部署更快、更可预测
- 更少的生产错误
- 出现问题立即反馈
- 消除发布日的集成挑战
- QA 团队在后期阶段花在手动测试上的时间更少
- 鼓励代码透明度和代码协作
- 更少的上下文切换
持续集成要求
- 监控中央存储库的 CI 服务器（在本地或云端设置）
- 对每个新的改进、功能或错误修复进行自动化测试
持续集成最佳实践
- 维护代码库
- 始终自动化软件构建
- 保持尽可能快的构建
- 进行自测构建（持续测试）
- 对基线的承诺应该每天发生
- 在生产环境的克隆中运行测试
- 轻松获取最新的可交付成果
- 使最新构建的结果透明
持续交付 vs 持续部署 vs 持续集成差异比较：持续交付 (CD)
在 CI 之上，持续交付还在集成和构建阶段之后提供自动发布流程。手动触发器控制部署到生产。
CD的主要目标是：
- 准备好时交付新功能
- 构建稳定、有弹性的系统
- 确保业务应用程序不间断运行
持续交付依赖于人来决定向用户发布什么以及何时发布。部署率取决于业务需求。
CD 的工作原理
持续交付 vs 持续部署 vs 持续集成有什么区别？开发人员通过 CI 过程添加改进、功能和错误修复。手动提交后，CD 工具通过自动部署管道获取代码。
持续交付通常有一个类似生产的暂存区，在最终版本中存在时间延迟。滞后允许在进入生产之前审查和手动接受代码中的更改。
持续交付的好处
- 加速发布周期
- 更快的上市时间
- 更少的时间用于准备和设置发布
- 增加迭代次数可降低风险、缩短恢复时间并提高客户满意度
- 在交付过程的早期发现错误
- 交付更高效、更安全
- 可预测的交付速度
- 更快的用户反馈循环
- 开发人员减少手动工作
持续交付要求
- 强大的 CI 基础
- 早期开发阶段的优化
- 涵盖足够代码库的测试套件
- 功能标志以防止不完整的功能影响生产中的用户
持续交付最佳实践
- 确保有一个强大的 CI 设置支持持续交付流程
- 调整你的软件系统以适应 CD，而不是相反
- 自动化尽可能多的流程
- 使用短而宽的部署管道
- 在开发和生产之间至少有一站
- 以相同的方式部署到所有环境
- 从版本控制驱动更改
- 将数据库包含在管道中
- 监控和记录交付管道
持续交付 vs 持续部署 vs 持续集成差异比较：持续部署 (CD)
在持续部署中，每次代码更改都经过自动化管道，应用程序的工作版本会自动发布到生产环境。
与持续交付不同，持续部署没有发布审批周期。由于没有手动触发器，此设置依赖于自动测试以防止错误到达最终用户。
持续部署的目标是实现几乎持续的更新发布。一旦开发人员编写和测试代码，用户就会收到更新。
持续部署的工作原理
持续交付遵循按需模型，而持续部署会自动推送每个部署。在合并到主线分支之前，所有测试都在类似生产的环境中进行。
持续部署不需要用于手动审查代码更改的临时区域。自动化测试发生在开发过程的早期并贯穿整个发布阶段。
随着Docker 等工具使应用程序部署自动化变得容易，持续交付和部署之间的差异将继续扩大。
持续部署的好处
- 无需人工干预的自动部署触发器
- 向最终用户部署每个新的主线添加
- 团队开发速度更快（发布没有停顿，手动、重复的任务更少）
- 小批量代码使发布风险更小且更易于修复
- 统一的管道集成了团队和流程
持续部署要求
- 一个优秀的测试套件
- 能够跟上部署步伐的文档流程
- 完善的功能标志系统，以支持重大更改的发布
持续部署最佳实践
- 维护一个中央代码存储库
- 尽可能多地自动化构建和部署过程
- 每天遵守基线
- 使用问题跟踪器进行开发任务
- 使用包含问题编号和所有更改描述的版本控制分支
哪种持续练习适合你？
持续交付 vs 持续部署 vs 持续集成差异比较：在你考虑哪种实践适合你之前，请了解你的团队必须拥有能够处理 CI/CD 的 DevOps 文化。你还应该考虑潜在的限制，例如合规性法律。法规可能会阻止组织使用持续部署。
如果你的团队有能力支持持续流程，请问自己以下问题：
- 你的团队是否需要在持续集成和交付之间手动触发？
- 你能否在未经利益相关者批准的情况下进行部署？
- 你能让你的用户接触到生产变化吗？
- 你对生产错误的响应时间是否很快？
- 你的门控要求是否允许端到端自动化
如果你对上述问题的回答是肯定的，那么持续部署可能是一个值得的选择。考虑自动化整个软件交付，从代码提交到生产。
如果你对某些或所有问题的回答是否定的，那么最好从持续集成和持续交付开始。考虑自动创建生产就绪代码，但手动批准部署。随着时间的推移，你的团队可以继续朝着软件交付过程的持续部署和完全自动化的方向发展。
做出合理的商业选择
持续交付 vs 持续部署 vs 持续集成有什么区别？持续流程有助于尽快构建、测试和发布软件，并尽可能减少错误。然而，某些方法在某些情况下比在其他情况下更有效。
团队必须了解持续集成、交付和部署之间的差异，才能充分利用这些实践。现在你已了解每个流程提供的功能，选择符合你需求的选项，并轻松过渡到 DevOps。
