使用持续交付可以更快地发布，成本和风险更小
持续交付是 DevOps 分类中的 8 项功能中的一种。
了解需要持续交付的原因
2012 年，软件部署错误导致当时美国股市最大的交易商骑士资本集团亏损 4.6 亿美元。
亏损是在市场开盘时开始的。 代码中没有 bug，问题是在手动部署到八台生产服务器中的一台时出错造成的。
当他们尝试修复此问题时，反而将所有这八台服务器都错误配置了，因而损失了更多资金。 由于所有部署都是手动的，因此他们无法自动回滚更改。
在试图解决这个问题 45 分钟后，他们最终关闭了整个系统。 在此期间，他们损失了 4.6 亿美元。
这是一个真实的故事。 对你的组织有什么启发？ 你还在手动部署吗？
为了帮助理解一个组织的交付性能，可能需要问的最重要的一个问题是：
重要
你的部署对生产的影响有多大？
工程师和技术人员在将代码投入生产时所感受到的那种恐惧和焦虑可以说明很多关于团队软件交付性能的信息。
什么是持续交付？
重要
持续交付是一种软件工程方法，团队通过此方法可以在短期内生成软件，从而确保软件可以：
- 随时可靠地发布
- 手动发布
持续交付的目的是：
- 以更快的速度和频率生成、测试和发布软件
- 通过允许对生产中的应用程序进行更多的增量更新来减少交付变更的成本、时间和风险
持续交付适用于以下情况：
- 软件可在其整个生命周期内进行部署
- 通过交付过程的所有可能部分（通常使用部署管道），可以实现持续集成和广泛的自动化
- 可以按需执行任何版本软件的推送按钮部署到任何环境
大型手动部署会极大地提高发布软件的复杂性，增加人为错误的可能性，并使识别和纠正部署故障变得更加困难，从而带来很高的风险。 部署频率低，变更的提前期长，平均恢复时间长且变更失败率高。
指定的运营团队在非工作时间执行手动部署。 他们需要一个手工步骤文档，并需要时间来手工测试记录的步骤。 大型部署还需要更长的执行时间，失败时更难回滚，并在部署后需要更大的测试范围。 每次部署的更改数量更大，反馈需要更多的时间来实现。
通过自动执行持续交付并使之能够随时发布到生产中，该过程能够带来众多且有意义的好处：
- 减少浪费
- ROI 更高
- 风险更低
- 质量更高
- 及早反馈
- 更好的规划
- 更快的协作
- 全员参与
- 生产问题更少
- 能够在安全方面进行左移
- 更快适应和反应
- 可预测性更高的版本
- 在任意营业时间部署
- 更快响应市场变化
- 及时交付变更
- 团队中的任何人都可以启动部署
- 快速、可重复且可配置的部署
根据《2019 年 DevOps 状态报告》，与低水平执行者相比，高效 DevOps 组织实现了：
- 部署频率提高 200 倍以上
- 更改的提前期快 100 倍以上
- 平均恢复时间快 2600 倍以上
- 更改失败率低 7 倍
此外，根据 CA Technologies 的一项全球研究，企业将上市时间缩短多达 20%，并增加了收入。
注意
持续交付有时会与持续部署混淆。 持续部署意味着每一个更改都经过管道并自动投入生产，因此每天都要进行许多生产部署。 持续交付只是意味着可以频繁地进行部署，但也可以选择不这样做，这通常是因为企业更喜欢较慢的部署速度。 必须执行持续交付才能执行持续部署。
持续集成是持续交付的先决条件。 适当的实践使你可以从源代码管理中随时生成和（可靠地）部署高质量应用程序。
