# OPS06-BP04 自動化測試和復原
<a name="ops_mit_deploy_risks_auto_testing_and_rollback"></a>

 為了提高部署程序的速度和可靠性，請在生產前和生產環境中制定自動化測試和回復功能的策略。在部署到生產環境時自動化測試，以模擬人類與系統的互動，驗證部署的變更。自動回復以快速回復到之前已知的良好狀態。回復應該在預先定義的條件下自動啟動，例如當未達到預期成果或自動化測試失敗時。將這兩項活動的自動化可以提高部署成功率，盡可能縮短回復時間，並減少對業務的潛在影響。

 **預期成果：**您的自動化測試和回復策略將整合至持續整合與持續交付 (CI/CD) 管道。您的監控能夠根據您的成功條件進行驗證，並在失敗時啟動自動回復。這會將終端使用者和客戶受到的任何負面影響降到最低。例如，當所有測試結果都達到標準時，您可以利用相同的測試案例，將程式碼提升至啟動自動迴歸測試的生產環境。若迴歸測試結果不符預期，則會在管線工作流程中啟動自動回復。

 **常見的反模式：**
+  您的系統架構並不允許以較小版本進行更新。因此，在部署失敗期間，您無法回復這些大量變更。
+  您的部署程序包含一系列手動步驟。將變更部署到工作負載之後，即可開始部署後測試。測試之後，您會發現工作負載無法運作，且客戶中斷連線。然後您開始回復到之前的版本。所有這些手動步驟都會延遲整體系統回復，並對客戶造成長期影響。
+  您花時間為應用程式中不常使用的功能開發自動化測試案例，因而大幅降低了自動化測試功能的投資報酬率。
+  您的版本包含彼此獨立的應用程式、基礎設施、修補程式和組態更新。但是，您有一個 CI/CD 管道可以一次交付所有變更。一個元件故障會強迫您還原所有變更，進而使回復過程變得複雜且效率低下。
+  您的團隊在第一個衝刺階段完成編碼，並開始衝刺兩項工作，但直到第三個衝刺階段，計畫中都不包括測試。最終，自動化測試找出第一個衝刺階段的缺漏，必須在測試第二個衝刺階段前解決，才能啟動交付項目，因此整個版本延遲，進而降低您的自動化測試效率。
+  生產版本的自動迴歸測試案例已經完成，但您並未監控工作負載的運作狀況。由於無法查看是否已重啟服務，您不確定是否需要回復或已啟動回復。

 **建立此最佳實務的優勢：**自動化測試可以提高測試流程的透明度，以及您在更短時間內顧及更多功能的能力。在生產環境中測試和驗證變更，可以立即識別出問題。改善自動化測試工具的一致性可以更精確地偵測問題。透過自動回復至舊版本，將對客戶的影響降至最低。自動化回復最終可減少業務影響，讓您對部署功能更有信心。整體而言，這些功能會減少 time-to-delivery，同時確保品質。

 **未建立此最佳實務時的曝險等級：**中 

## 實作指引
<a name="implementation-guidance"></a>

 自動測試已部署的環境，更快確認是否達到預期成果。當無法達成預先定義的結果時，自動還原到先前的良好狀態，以盡量縮短還原時間，並減少由手動程序引起的錯誤。將測試工具與管道工作流程整合，持續進行測試並減少手動輸入。優先處理自動化測試案例，例如減緩最高風險且需要在每次變更時經常測試的案例。此外，還可以根據測試計畫中預先定義的特定條件進行自動回復。

### 實作步驟
<a name="implementation-steps"></a>

1.  為您的開發生命週期建立測試生命週期，定義需求規劃到測試案例開發、工具配置、自動化測試和測試案例結案等每個測試程序階段。

   1.  根據您的整體測試策略建立針對特定工作負載的測試方式。

   1.  在整個開發生命週期中，考慮適當的連續測試策略。

1.  根據您的業務需求和管道投資，選擇用於測試和回復的自動化工具。

1.  決定您應該分別自動化和手動執行哪些測試案例。這些內容皆可以根據受測功能的業務價值優先順序來決定。使所有團隊成員隨時接收計畫最新資訊，並確認執行手動測試的權責分配。

   1.  將自動化測試功能應用於對自動化有意義的特定測試案例，例如可重複或經常執行的案例、需要重複作業的案例，或跨多個組態所需的案例。

   1.  在自動化工具中定義測試自動化指令碼和成功條件，如此一來，當特定案例失敗時，可以啟動持續的工作流程自動化。

   1.  定義自動回復的特定失敗條件。

1.  測試案例其中複雜度和人工互動具較高的失敗風險，因此必須排定測試自動化的優先順序，透過詳盡的測試案例開發來產生一致的結果。

1.  將您的自動化測試和回復工具整合到 CI/CD 管道。

   1.  為變更制定明確的成功條件。

   1.  監控觀察以偵測這些條件，並在符合特定回復條件時自動回復變更。

1.  執行不同類型的自動化生產測試，例如：

   1.  A/B 測試，以顯示結果比較兩個使用者測試組之間的當前版本。

   1.  Canary 測試讓您能在將變更發佈給所有使用者之前，先將其發佈給一部分使用者。

   1.  功能旗標測試允許您從應用程式外部標記新版本的功能 (每次僅限一個)，進而使每個新功能皆能逐一進行驗證。

   1.  迴歸測試，以現有的關聯元件驗證新功能。

1.  透過其他應用程式和元件，監控應用程式、交易和互動的操作面向。開發報告，以便按照工作負載顯示變更成功率，讓您得以識別出能夠進一步最佳化的自動化和工作流程部分。

   1.  開發測試結果報告，協助您快速決定是否應該調用回復程序。

   1.  實施策略，允許根據一個或多個測試方法導出的預定義失敗條件進行自動回復。

1.  開發自動化測試用例，以便在未來可重複的變更中重複使用。

 **實作計劃的工作量：**中 

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [OPS06-BP01 計畫變更失敗](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) 
+  [OPS06-BP02 測試部署](ops_mit_deploy_risks_test_val_chg.md) 

 **相關文件：**
+ [AWS Builders Library \$1 確保部署期間的復原安全 ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+  [使用 重新部署和復原部署 AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html) 
+ [ 使用 自動化部署時的 8 個最佳實務 AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)

 **相關範例：**
+ [ 使用 Selenium AWS LambdaAWS Fargate、 和 AWS 開發人員工具進行無伺服器 UI 測試 ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)

 **相關影片：**
+ [re:Invent 2020 \$1 無人為介入：Amazon 的自動化持續交付管道](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon 的高可用性部署方法](https://www.youtube.com/watch?v=bCgD2bX1LI4)