持续流程对于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。
