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