# OPS 6. 如何緩解部署風險？
採用可快速提供品質意見回饋，並從成果不盡理想的改變中快速復原的方法。使用這些實務可緩解部署變更所帶來問題的影響。
**Topics**
+ [
# OPS06-BP01 計畫變更失敗
](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [
# OPS06-BP02 測試部署
](ops_mit_deploy_risks_test_val_chg.md)
+ [
# OPS06-BP03 採用安全的部署策略
](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [
# OPS06-BP04 自動化測試和復原
](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 計畫變更失敗
計劃在部署造成非預期成果時恢復到已知的良好狀態，或者在生產環境中進行修復。擁有制定這類計畫的政策可以協助所有團隊訂立政策，從失敗變更中恢復。一些範例策略包括部署和回復步驟、變更政策、功能旗標、流量隔離和流量轉移。單一版本可能包含多個相關元件變更。策略要能提供您承受或從任何失敗元件變更中恢復的能力。
**預期成果：**您已經為失敗變更準備了詳細的恢復計畫。此外，您也縮減了發行版本的大小，如此一來，對其他工作負載元件的潛在影響將降到最低。因此，您可以縮短因變更失敗而造成的可能停機時間，並提高回復時間的彈性和效率，進而降低對業務的影響。
**常見的反模式：**
+ 您執行了部署，而您的應用程式變得不穩定，但系統中似乎有作用中使用者。您必須決定是否要復原變更並影響作用中使用者，或在知道使用者無論如何都會受到影響的情況下，等待復原變更。
+ 在進行路由變更後，您可以存取新的環境，但其中一個子網路變成無法連線。您必須決定是否要復原所有項目，或嘗試修正無法存取的子網路。當您做出該決定時，子網路仍無法連線。
+ 您的系統架構並不允許以較小版本進行更新。因此，在部署失敗期間，您無法回復這些大量變更。
+ 您未使用基礎設施即程式碼 (IaC)，並且以手動方式更新了基礎設施，從而造成不理想的組態。您無法有效追蹤和還原手動變更。
+ 由於您尚未測量部署的增加頻率，您的團隊不會想降低變更規模和改善每次變更的回復計畫，進而造成更高的風險和失敗率。
+ 請不要測量因變更失敗而導致中斷的總持續時間。您的團隊無法排定優先順序並改善其部署程序和回復計畫的效能。
**建立此最佳實務的好處：**擁有從失敗變更中復原的計畫，可最大限度地減少復原的平均時間 （MTTR），並減少您的業務影響。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
發行團隊採用的一致記錄政策和實務可讓組織規劃發生失敗變更時應採取的動作。該政策應允許在特定情況下向前修正。在任何情況下，向前修正或回復計畫都應該在部署到現場生產之前先經過詳細記錄和測試，以將回復變更所需的時間降到最低。
### 實作步驟
1. 記錄要求團隊有效計畫在特定期間內還原變更的政策。
1. 政策應指明允許向前修正的情況。
1. 要求所有參與者皆能存取記錄完善的回復計畫。
1. 指定回復需求 (例如：發現部署未經授權的變更時)。
1. 分析工作負載每個元件相關所有變更的影響程度。
1. 如果可重複的變更遵循強制執行變更政策的一致工作流程，則允許這些變更進行標準化、範本化和預先授權。
1. 縮小變更規模以減少任何變更的潛在影響，進而降低回復時間和對業務的影響。
1. 確保回復程序會將程式碼回復到已知的良好狀態，避免可能發生的意外。
1. 整合工具和工作流程，以程式設計方式執行政策。
1. 讓其他工作負載擁有者可以看到變更相關資料，以改善任何無法回復失敗變更的診斷速度。
1. 使用可見的變更資料來衡量這項實務的成效，並識別出反覆改進方式。
1. 使用監控工具來驗證部署成敗，以加速回復的決策過程。
1. 測量失敗變更期間的中斷時間，以持續修正回復計畫。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS06-BP04 自動化測試和復原](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相關文件：**
+ [AWS Builders Library \$1 確保部署期間的復原安全 ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS 白皮書 \$1 雲端的變更管理 ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**相關影片：**
+ [re:Invent 2019 \$1 Amazon 的高可用性部署方法](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 測試部署
使用與生產環境相同的部署組態、安全控制、步驟和程序，在生產前測試發行程序。驗證所有部署的步驟均按照預期完成，例如檢查檔案、組態和服務。透過功能、整合和負載測試以及任何監控 (例如運作狀態檢查) 進一步測試所有變更。透過這些測試，您可以及早發現部署問題，有機會在生產前進行規劃和問題緩解。
您可以建立暫時的平行環境來測試每項變更。使用基礎設施即程式碼 (IaC) 來自動化測試環境的部署，協助減少涉及的工作量，並確保穩定性、一致性和更快的功能交付。
**預期成果：**您的組織採用測試驅動型開發文化，其中包含測試部署。如此一來，便能確保團隊專注於交付商業價值，而非管理發行版本。團隊會及早找出部署風險，並訂定適當的緩解方案。
**常見的反模式：**
+ 使用生產版本期間，因為未經測試的部署經常會導致問題，而需要疑難排解或升級處理。
+ 您的版本包含更新現有資源的基礎設施即程式碼 (IaC)。您不確定 IaC 是否會成功執行，或對資源造成影響。
+ 您為應用程式部署一個新功能。該功能無法按照您的預期運作，且在受影響的使用者回報之前無法預見問題。
+ 您更新憑證。您不小心將憑證安裝到錯誤的元件，這些元件未被偵測並因為無法建立與網站的安全連線，而影響了網站訪客。
**建立此最佳實務的優勢：**針對部署程序的生產前階段及其帶來的變更進行廣泛測試，將部署步驟對生產的潛在負面影響降到最低。這麼做能增加產品發行期間的信心，並盡可能減少操作支援，同時不影響交付變更的速度。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
測試部署程序與測試部署所產生的變更同樣重要。您可以在生產前環境中測試部署步驟，盡可能準確反映生產環境。諸如不完整或錯誤部署步驟，或者配置錯誤等常見問題都能在生產環境之前偵測。此外，您也可以測試回復步驟。
**客戶範例**
作為持續整合和持續交付 （CI/CD） 管道的一部分， AnyCompany Retail 會執行在類似生產環境中為其客戶發佈基礎設施和軟體更新所需的定義步驟。流程包含許多預先檢查程序，可以在部署之前偵測到資源偏移 (偵測 IaC 以外所執行的資源變更)，以及驗證 IaC 啟動時所採取的動作。這個程序會驗證部署步驟，例如確認特定檔案和組態已準備就緒，或服務處於執行狀態，並在向負載平衡器重新註冊之前，正確回應本機上的運作狀態檢查。此外，所有變更都標記了許多自動化測試，例如功能、安全性、迴歸、整合和負載測試。
### 實作步驟
1. 執行安裝前檢查，將生產前環境反映到生產環境。
1. 使用[偏離偵測](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)來偵測 資源是否已在 之外變更 CloudFormation。
1. 使用[變更集](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html)來驗證堆疊更新的意圖是否符合啟動變更集時 CloudFormation 採取的動作。
1. 這會觸發 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) 中的手動核准步驟，以授權生產前環境的部署。
1. 使用[AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html)檔案等部署組態來定義部署和驗證步驟。
1. 在適用的情況下，[AWS CodeDeploy 與其他 AWS 服務整合](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或與[AWS CodeDeploy 合作夥伴產品和服務整合。](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)
1. 使用 Amazon CloudWatch AWS CloudTrail、 和 Amazon SNS事件通知來[監控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 執行部署後自動化測試，包括功能、安全性、迴歸、整合和負載測試。
1. 對部署問題[進行故障診斷](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
1. 成功驗證前述步驟後，應該啟動手動核准工作流程，以授權部署到生產環境。
**實作計劃的工作量：**高
## 資源
**相關的最佳實務：**
+ [OPS05-BP02 測試並驗證變更](ops_dev_integ_test_val_chg.md)
**相關文件：**
+ [AWS Builders' Library \$1 自動化安全、移交部署 \$1 測試部署 ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS 白皮書 \$1 在 上練習持續整合和持續交付 AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [阿波羅的故事 - Amazon 的部署引擎](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+ [如何在運送程式碼之前在 AWS CodeDeploy 本機進行測試和偵錯](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [整合網路連線測試與基礎設施部署](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**相關影片：**
+ [re:Invent 2020 \$1在 Amazon 測試軟體和系統](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**相關範例：**
+ [ 教學課程 \$1 透過驗證測試部署 和 Amazon ECS服務 ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 採用安全的部署策略
安全的生產部署可控制有益變更的流程，目的是將這些變更對客戶造成的任何影響降到最低。安全控制提供檢查機制，以驗證所需的結果，並限制變更引入的任何缺陷或部署失敗造成的影響範圍。安全推出可能包括諸如功能旗標、一體式、滾動式 (Canary 版本)、不可變、流量拆分和藍/綠部署等策略。
**預期成果：**您的組織使用持續整合持續交付 (CI/CD) 系統，可提供自動化安全部署的功能。團隊必須使用適當的安全推出策略。
**常見的反模式：**
+ 您一次性將失敗的變更部署至所有生產環境。因此，所有客戶都會同時受到影響。
+ 同時部署到所有系統中引入的缺陷需要緊急釋放。為所有客戶修正它需要數天的時間。
+ 管理生產發行需要多個團隊的規劃和參與。這會限制您為客戶經常更新功能的能力。
+ 您透過修改現有系統來執行可變部署。發現變更失敗之後，您必須再次修改系統以還原舊版本，這會延長回復時間。
**建立此最佳實務的優勢：**自動化部署在推出速度和持續為客戶提供有益變更之間取得了平衡。限制影響範圍可以預防損失慘重的部署失敗，並盡可能提高團隊有效回應故障的能力。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
持續交付失敗可能導致服務可用性降低和糟糕的客戶體驗。為了盡可能提高部署成功率，請在端對端發行程序中實施安全控制，盡量減少部署錯誤，而目標則是實現零部署失敗。
**客戶範例**
AnyCompany Retail 的使命是實現最小至零停機時間的部署，這表示部署期間沒有對使用者產生任何可感知的負面影響。為此，公司已建立了部署模式 (請參閱下列工作流程圖表)，例如滾動部署和藍/綠部署。所有團隊都在其 CI/CD 管道中採用一個或多個模式。
| Amazon EC2 的 CodeDeploy 工作流程 | Amazon ECS 的 CodeDeploy 工作流程 | Lambda 的 CodeDeploy 工作流程 |
| --- | --- | --- |
| ![\[Amazon EC2 的部署程序流程\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/deployment-process-ec2.png) | ![\[Amazon ECS 的部署程序流程\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/deployment-process-ecs.png) | ![\[Lambda 的部署程序流程\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/images/deployment-process-lambda.png) |
### 實作步驟
1. 推廣到生產之後，使用核准工作流程可啟動生產推出步驟的一系列動作。
1. 使用自動化部署系統，例如 [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)。AWS CodeDeploy [部署選項](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html)包括適用於 EC2/內部部署的就地部署，以及適用於 EC2/內部部署、AWS Lambda 和 Amazon ECS 的藍/綠部署 (請參閱上述工作流程圖)。
1. 在適用的情況下，[將 AWS CodeDeploy 與其他 AWS 服務整合](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或者[將 AWS CodeDeploy 與合作夥伴的產品和服務整合](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)。
1. 對 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) 和 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) 等資料庫使用藍/綠部署。
1. 使用 Amazon CloudWatch、AWS CloudTrail 和 Amazon Simple Notification Service (Amazon SNS) 事件通知來[監控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 執行部署後自動化測試，包括功能、安全性、迴歸、整合和任何負載測試。
1. 對部署問題[進行故障診斷](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [OPS05-BP02 測試並驗證變更](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 進行頻繁、小型、可逆的變更](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 完全自動化整合和部署](ops_dev_integ_auto_integ_deploy.md)
**相關文件：**
+ [AWS 建置者資料中心 \$1 自動化安全、無人為介入的部署 \$1 生產部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS 建置者資料中心 \$1 我的 CI/CD 管道是我的發行主管 \$1 安全、自動的生產發行](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS 白皮書 \$1 在 AWS 上實行持續整合和持續交付 \$1 部署方法](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [AWS CodeDeploy使用者指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [使用 AWS CodeDeploy 中的部署組態](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [設定 API Gateway Canary 發行部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS 部署類型](https://docs.aws.amazon.com/)
+ [Amazon Aurora 和 Amazon RDS 中的全受管藍/綠部署](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [使用 AWS Elastic Beanstalk 的藍/綠部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
**相關影片：**
+ [re:Invent 2020 \$1 無人為介入：Amazon 的自動化持續交付管道](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon 的高可用性部署方法](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**相關範例：**
+ [在 AWS CodeDeploy 中嘗試使用藍/綠部署範例](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [ 研討會 \$1 使用 AWS CDK 建置 Lambda Canary 部署的 CI/CD 管道](https://catalog.workshops.aws/cdk-cicd-for-lambda-canary-deployment/en-US)
+ [ 研討會 \$1 利用 Amazon ECS 建置您的第一個 DevOps 藍/綠管道 ](https://catalog.us-east-1.prod.workshops.aws/workshops/4b59b9fb-48b6-461c-9377-907b2e33c9df/en-US)
+ [ 研討會 \$1 利用 Amazon EKS 建置您的第一個 DevOps 藍/綠管道 ](https://catalog.us-east-1.prod.workshops.aws/workshops/4eab6682-09b2-43e5-93d4-1f58fd6cff6e/en-US)
+ [ 研討會 \$1 EKS GitOps 搭配 ArgoCD ](https://catalog.workshops.aws/eksgitops-argocd-githubactions)
+ [ 研討會 \$1 AWS 上的 CI/CD 研討會 ](https://catalog.workshops.aws/cicdonaws/en-US)
+ [ 針對容器型 Lambda 函數使用 AWS SAM 實作跨帳戶 CI/CD ](https://aws.amazon.com/blogs/compute/implementing-cross-account-cicd-with-aws-sam-for-container-based-lambda/)
# OPS06-BP04 自動化測試和復原
為了提高部署程序的速度和可靠性，請在生產前和生產環境中制定自動化測試和回復功能的策略。在部署到生產環境時自動化測試，以模擬人類與系統的互動，驗證部署的變更。自動回復以快速回復到之前已知的良好狀態。回復應該在預先定義的條件下自動啟動，例如當未達到預期成果或自動化測試失敗時。將這兩項活動的自動化可以提高部署成功率，盡可能縮短回復時間，並減少對業務的潛在影響。
**預期成果：**您的自動化測試和回復策略將整合至持續整合與持續交付 (CI/CD) 管道。您的監控能夠根據您的成功條件進行驗證，並在失敗時啟動自動回復。這會將終端使用者和客戶受到的任何負面影響降到最低。例如，當所有測試結果都達到標準時，您可以利用相同的測試案例，將程式碼提升至啟動自動迴歸測試的生產環境。若迴歸測試結果不符預期，則會在管線工作流程中啟動自動回復。
**常見的反模式：**
+ 您的系統架構並不允許以較小版本進行更新。因此，在部署失敗期間，您無法回復這些大量變更。
+ 您的部署程序包含一系列手動步驟。將變更部署到工作負載之後，即可開始部署後測試。測試之後，您會發現工作負載無法運作，且客戶中斷連線。然後您開始回復到之前的版本。所有這些手動步驟都會延遲整體系統回復，並對客戶造成長期影響。
+ 您花時間為應用程式中不常使用的功能開發自動化測試案例，因而大幅降低了自動化測試功能的投資報酬率。
+ 您的版本包含彼此獨立的應用程式、基礎設施、修補程式和組態更新。但是，您有一個 CI/CD 管道可以一次交付所有變更。一個元件故障會強迫您還原所有變更，進而使回復過程變得複雜且效率低下。
+ 您的團隊在第一個衝刺階段完成編碼，並開始衝刺兩項工作，但直到第三個衝刺階段，計畫中都不包括測試。最終，自動化測試找出第一個衝刺階段的缺漏，必須在測試第二個衝刺階段前解決，才能啟動交付項目，因此整個版本延遲，進而降低您的自動化測試效率。
+ 生產版本的自動迴歸測試案例已經完成，但您並未監控工作負載的運作狀況。由於無法查看是否已重啟服務，您不確定是否需要回復或已啟動回復。
**建立此最佳實務的優勢：**自動化測試可以提高測試流程的透明度，以及您在更短時間內顧及更多功能的能力。在生產環境中測試和驗證變更，可以立即識別出問題。改善自動化測試工具的一致性可以更精確地偵測問題。透過自動回復至舊版本，將對客戶的影響降至最低。自動化回復最終可減少業務影響，讓您對部署功能更有信心。整體而言，這些功能會減少 time-to-delivery，同時確保品質。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
自動測試已部署的環境，更快確認是否達到預期成果。當無法達成預先定義的結果時，自動還原到先前的良好狀態，以盡量縮短還原時間，並減少由手動程序引起的錯誤。將測試工具與管道工作流程整合，持續進行測試並減少手動輸入。優先處理自動化測試案例，例如減緩最高風險且需要在每次變更時經常測試的案例。此外，還可以根據測試計畫中預先定義的特定條件進行自動回復。
### 實作步驟
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. 開發自動化測試用例，以便在未來可重複的變更中重複使用。
**實作計劃的工作量：**中
## 資源
**相關的最佳實務：**
+ [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)