總結
在本課程模組中，您已將 部署模式 定義為自動方式，以順暢地向使用者推出新的應用程式功能。 良好的部署模式可協助您將停機時間降到最低。 它也可讓您逐漸向使用者推出新功能。
您可以選擇數種部署模式。 您選擇的部署模式取決於您的部署原因和資源。 您是否已有適當的 Canary 測試人員？ 您是否會運用深色啟動，並選擇不知道其為測試人員的測試人員？ 如果您有一組受信任的測試人員，會逐漸從一個小集合增加到較大的集合，則可以選擇漸進式曝光部署。 或者，如果您想要知道某個版本是否比另一個版本執行得更好，您可以選擇 A/B 測試。
Tailspin 小組選擇使用 Azure App Service 中的部署位置來實作藍綠色部署模式。 「部署位置」是具有專屬主機名稱的即時應用程式。 小組可以交換兩個部署位置。 藉由交換，他們可以立即促成生產上的變更。 雖然小組尚未準備好將其網站發佈給公眾，但他們已證明，他們可以向使用者取得新功能，而不會造成停機時間。
此外，在本課程模組中，您還了解了如何藉由還原 Git 認可，然後透過管線推送還原的變更，向前復原非預期的變更。
小組如何評估？
稍早在小組的 DevOps 旅程中，Mara 曾經執行價值流映射練習，以協助小組分析其目前的發行週期過程。
回想一下， 活動比率或效率是 處理時間 除以 總前置時間：
$${活動比率\ =\ }{\dfrac{處理時間}{總交期時間}}$$
Tailspin Web 小組最初使用此計量來判斷其效率為 23%。
當小組實作持續整合時，小組首先減少了一些效率低下。 通過推行持續交付（CD），他們現在進一步減少了效率低下的問題。
在先前的學習路徑中，小組已減少：
為新功能設定原始檔控制所需的時間。 所需的時間從 三天 到 零天。
小組藉由從集中式原始檔控制移至 Git 來達成這項改進，這是分散式原始檔控制的形式。 使用分散式原始檔控制，不需要等候檔案解除鎖定。
將程式代碼傳遞給測試人員 Amita 所需的時間。 所需的時間從 兩天 到 零天。
小組藉由將其建置程式移至 Azure Pipelines 來達成這項改善。 Azure Pipelines 會在有組建可用時自動通知 Amita。 開發人員不再需要更新 Amita 的試算表來通知她。
Amita 測試新功能所花費的時間。 所需的時間從 三天 到 一天。
小組藉由單元測試其程式代碼來達成這項改進。 每次變更移動通過組建管線時，小組即會執行單元測試， 因此 Amita 會接觸到較少錯誤 (bug) 和迴歸。 減少的工作負載表示 Amita 可以更快完成每個手動測試。
您和小組在此學習路徑中建置的發行管線已減少：
將組建推進到 測試 階段所需的時間。 所需的時間從 三天 到 一天。
小組使用排程的觸發程式在每天上午 3:00 部署「測試」，達成了這項改善。
使經過測試的組建進入「預備」所花費的時間。 所需的時間從 兩天 到 零天。
小組藉由將功能測試形式的 Selenium UI 測試新增至 測試 階段，以達成這項改進。 這些自動化測試比手動版本快得多。
使核准的組建從「預備」環境上線所花費的時間。 所需的時間從 一天 到 不到一天。
小組藉由將手動核准檢查新增至管線來達成這項改善。 當管理人員簽核時，Tim 可以將變更的發行時間從「預備」變成即時。
這些變更會將總潛在客戶時間從 22 天減少到 10 天。 當我們將這些數位替換成方程式時：
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{10\ days}}{ = 0.50}$$
將結果乘以 100%，我們得到 50% 的減少。
雖然總有改進空間，但這項變更對球隊來說是一場勝利。 Tailspin 小組現在不僅能更快獲得價值，還花較少的時間等待，並花更多的時間執行他們最喜歡的功能：提供他們知道客戶會喜歡的功能。
瞭解更多資訊
您可以使用這些額外的資源來深入了解 App Service、部署位置和回復的變更：