摘要

  • 3 分鐘

在本課程模組中，您已將「部署模式」定義為可順暢地將新應用程式功能推出給使用者的自動化方式。 良好的部署模式可協助您將停機時間減至最少。 它還可以讓您逐步推出新功能給使用者。

您可以從數個部署模式中進行選擇。 您選擇的部署模式會依您的部署原因和資源而定。 您是否已有適當的 Canary 測試人員？ 您是否會運用深色啟動，並選擇不知道其為測試人員的測試人員？ 如果您有一組受信任的測試人員，則這些測試人員會逐漸從較小的集合增加為較大的集合，然後您即可選擇漸進式部署。 或者，如果您想要知道某個版本的執行效能是否優於另一個版本，則可以選擇 A/B 測試。

Tailspin 小組選擇使用 Azure App Service 中的部署位置來實作藍綠部署模式。 「部署位置」是具有專屬主機名稱的即時應用程式。 小組可以交換兩個部署位置。 藉由交換，其可以立即將變更升階到生產。 雖然小組未準備好發行其網站供大眾使用，但其已證明他們可以在不產生停機時間的情況下為使用者取得新功能。

此外，在本課程模組中，您還了解了如何藉由還原 Git 認可，然後透過管線推送還原的變更，向前復原非預期的變更。

小組如何評估？

在「評估您現有的軟體開發流程」課程模組中，Mara 進行了價值串流對應練習。 此練習有助於小組分析其目前的發行週期流程。

您應該記得，「活動比例」或效率為「處理時間」除以「總前置時間」：

$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$

Tailspin Web 小組一開始會使用此計量來確定其效率是否為 23%。

當小組在實作持續整合 (CI) 時，會先減少一些效率不佳的情況。 藉由套用持續傳遞 (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、部署位置和回復的變更：