问题描述
在向某人解释DevOps时，经常会遇到这样的问题：
敏捷方法中的发布管理与瀑布方法有何不同？
因此，您可以使用什么样的标准来向这样的受众解释这些差异呢？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
DevOps、持续交付与发布
首先，需要明确DevOps是一种文化，类似于敏捷（不涉及特定敏捷方法）。因此，你并不是在”做” DevOps，而是在做一种被称为持续交付的发布方法，作为DevOps文化的一部分。
Jez Humble等人在他们的书中给出了持续交付的定义：
持续交付是一种能够以可持续的方式安全、快速地将各种变更（包括新特性、配置更改、错误修复和实验）引入生产环境或用户手中的能力。我们的目标是使部署——不管是大规模分布式系统、复杂的生产环境、嵌入式系统还是应用程序——成为可以按需执行的预测性、常规性任务。我们通过确保我们的代码始终处于可部署状态来实现这一目标，即使在成千上万名开发人员每天进行更改的情况下，我们的代码也始终如一。我们因此完全消除了传统上在“开发完成”后的“集成、测试和硬化”阶段以及代码冻结阶段进行的工作。
因此，持续交付确保代码能够在任何时候都处于可部署状态，并能够快速、安全地将变更引入生产环境。
敏捷方法与瀑布方法的差异
在敏捷方法和瀑布方法中，发布管理方面存在明显的差异。以下是这些差异的一些标准：
- 发布事件：敏捷方法下，发布事件频繁，可能每个迭代都会进行一次小范围发布；而瀑布方法下，发布事件较为稀少，通常在项目完成后进行一次大规模发布。
- 风险：敏捷方法中，由于频繁的小范围发布，风险较小；而瀑布方法中，由于大规模的单次发布，风险较高。
- 所需努力：敏捷方法下，持续交付使得发布过程更加平稳；而瀑布方法下，由于大规模的单次发布，可能需要投入较大的努力以确保一切正常。
- 变更量：敏捷方法下，每次迭代的变更量通常较小；而瀑布方法下，由于单次发布，变更量较大。
此外，您可以通过一个用户所体验到的例子来感受敏捷和瀑布方法的差异。想象一下使用某种软件（如Linux发行版）时，你可以选择以下两种发布方式之一：
- 滚动式发布（敏捷方法）：软件会频繁地进行小范围的更新，以不断改进和优化。
- 长期支持发布（瀑布方法）：软件会较少进行更新，但每次更新可能涉及更大的变化。
通过这个例子，可以更好地理解敏捷和瀑布方法在发布管理方面的不同之处。
正文完