概要
在本模块中，你已将 部署模式 定义为一种自动方式，以顺利向用户推出新的应用程序功能。 良好的部署模式有助于最大程度地减少停机时间。 它还使你能够逐步向用户推出新功能。
可以从多个部署模式中进行选择。 您选择的部署模式取决于您部署的原因和资源。 你是否部署了金丝雀测试人员？ 你是否将采用摸黑启动并选择不知道自己所担任身份的测试人员？ 如果你有一组可信的测试人员，这组人员数量从小集合逐步增多为大集合，那么你可以选择渐进式公开部署。 或者，如果想要知道一个版本的性能是否优于另一个版本，则可以选择 A/B 测试。
Tailspin 团队选择使用 Azure 应用服务中的部署槽位实现蓝绿部署模式。 部署槽位是自带主机名的实时应用。 团队可以交换两个部署槽位。 通过交换，他们可以立即将更改应用于生产环境。 尽管团队尚未准备好向公众发布其网站，但他们已经证明，他们可以向用户获取新功能，而不会造成停机。
另一项优势是，你还在本模块中学习了如何通过还原 Git 提交，再通过管道推送还原后的提交来对意外更改进行前滚。
团队的表现如何？
在团队的 DevOps 旅程中，Mara 执行了价值流映射练习，帮助团队分析其当前的发布周期过程。
回想一下，活动比率或效率是处理时间除以总交付时间。
$${活动比率\ =\ }{\dfrac{处理时间}{总交付时间}}$$
Tailspin Web 团队最初使用此指标来确定其效率为 23%。
团队在实施持续集成（CI）时首先减少了一些低效之处。 通过应用持续交付（CD），他们现在进一步降低了效率低下。
在以前的学习路径中，团队减少了：
为新功能设置源代码管理所需的时间。 所需时间从 三天 到 零天。
团队通过从集中式源代码管理迁移到 Git（一种分布式源代码管理形式）实现了这种改进。 通过使用分布式源代码管理，无需等待文件解锁。
将代码交付给测试人员 Amita 所需的时间。 所需时间从 两天 到 零天。
团队通过将生成过程迁移到 Azure Pipelines 来实现此改进。 当生成可用时，Azure Pipelines 会自动通知 Amita。 开发人员不再需要更新 Amita 的电子表格来通知她。
Amita 测试新功能所需的时间。 所需的时间从 三天 到 一天。
团队通过对代码进行单元测试来实现此改进。 每次更改通过生成管道移动时，他们都会运行单元测试，因此 Amita 看到的 bug 更少，性能降低得也更少。 减少的工作负荷意味着 Amita 可以更快地完成每个手动测试。
你和你的团队在此学习路径中构建的发布管道减少了：
将生成引入测试阶段所需的时间。 所需的时间从 三天 到 一天。
团队通过使用定时触发器每天凌晨3:00部署到测试以实现此目的。
将测试后的生成引入过渡阶段所需的时间。 所需时间从 两天 到 零天。
该团队通过将 Selenium UI 测试（一种功能测试）添加到 测试 阶段来实现此改进。 这些自动测试比手动版本快得多。
获取获批版本从暂存环境到上线状态所需的时间。 所需时间从 一天 到 不到一天。
团队通过向管道添加手动审批检查来实现此改进。 当管理层签字批准时，Tim 可将更改从过渡阶段发布到上线阶段。
这些更改将总交付周期从 22 天减少到 10 天。 当我们将这些数字替换为公式时：
$${活动比率\ =\ }{\dfrac{5\ 天}{10\ 天}}{ = 0.50}$$
将结果乘以 100%，我们将得到 50% 的减少。
虽然总有改进空间，但这种变化对球队来说是一场胜利。 Tailspin 团队现在不仅能更快地获得价值，而且花更少的时间等待和更多时间执行他们最喜欢的功能：提供他们知道客户会喜欢的功能。
了解详细信息
通过下方附加资源详细了解应用服务、部署槽位和回滚更改：