持续交付部署模型
- 4 分钟
你已经了解了“大规模部署”作为软件交付模型的诸多弊端，但知道这些弊端仅成功了一半。 在本单元中，你将了解该单一方法的替代方法，以及它如何帮助你达成提高可靠性的目标。
什么是持续交付？
持续交付是一种方法，你通过该方法可以更快、更省力、风险更低以及更具可重现的方式使软件更改可用。 持续交付不是使每个软件部署或更新都成为一个史诗式事件，而是力争将其转变为按需发生的快速、日常、可预测的体验。
部署频率：使用持续交付模型，经常需要进行部署。 通常，可能需要每月、每周、每日甚至每小时部署一次。 关键是你将更频繁地部署较小的更具针对性的更改。
由代码提交启动：部署不是提前计划的，而是在提交代码时进行的。 该代码可以是软件、基础结构，甚至可以是软件配置之类的内容。
自动测试：不仅可以使用集成的自动测试来测试代码，还可以提供有关这些测试结果的快速反馈。 正是这种快速反馈让你可以快速循环访问失败的测试并从中进行恢复。
在代码经过测试后，即可在一系列分阶段的环境（例如测试、QA 等）中端对端地测试部署。 在这些环境中滚动部署将成为部署体验不可或缺的一部分。
历史记录：你不仅希望获得部署活动的历史记录，而且还希望能够在任何给定时间协调生产环境。 你想要了解哪个部署创建了当前的生产环境。 利用这些知识，你就可以追溯诸如配置、测试结果以及代码本身之类的内容，一直追溯到触发部署的单个拉取请求。
部署目标
现在你已经了解持续交付的工作原理，请考虑使用 DevOps 实践（例如持续交付）部署软件解决方案可以达成的目标。
目标 1：降低与部署服务有关的压力，同时提高这些服务的可靠性
这是一种双赢；不仅可以通过降低与软件和基础结构部署有关的压力来提高工作满意度，还可以通过使系统更加可靠来提高工作满意度和最终用户满意度。 考虑到对客户体验的积极影响，从技术上讲，这是一种三赢模式。
目标 2：缩短你知道需要进行更改与将更改部署到生产之间的时间
例如，假定你已经确定了影响收入的代码缺陷。 你确切地了解问题所在以及如何编写此修复程序。 你需要花费多长时间将该代码投入生产？ 需要几个步骤？ 如何测试？ 借助 DevOps 实践，可以编码提交、吃午餐，以及在返回办公桌之前就收到问题已解决的通知。
目标 3：缩短创意和交付可用软件之间的时间
这与上一个目标非常相似，但我们不是在实现更改，而是在谈论纯粹的创新。 你在实施创新方面需要花费多长时间？ 利用此部署模型，你可以将新概念集成到生产系统中，并确信所添加的创新不会以任何方式中断当前系统。 有了这种信心，你即可快速交付新功能。
部署结果
本单元讨论的目标并非仅是理论上的愿望，它们是可以实现的。 以下是来自 DevOps Research and Assessment (DORA) 和 Google Cloud DevOps & SRE 发布的 2019 Accelerate State of DevOps Report 中的一些统计信息。 其中，他们发现“高效”DevOps 公司：
- 部署数量是 208 倍。
- 从提交到部署的速度快 106 倍。
- 更改失败率低 7 倍。
- 事件恢复时间快 2,604 倍。
这一切都有助于增加收入并缩短产品上市时间。
这些数字证实了部署实践很重要的创意。