# 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-BP08 テストとロールバックを自動化する](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 変更の失敗に備える
デプロイが望ましくない結果をもたらした場合に、既知の良好な状態に戻すか、本番環境で修正を行うことを計画します。このような計画を確立するためのポリシーを用意しておくと、すべてのチームが変更の失敗から復旧する戦略を策定するうえで役立ちます。戦略の例として、デプロイとロールバック手順、ポリシーの変更、機能フラグ、トラフィックの分離、トラフィックシフトなどがあります。1 つのリリースに、関連するコンポーネントの変更が複数含まれる場合があります。この戦略は、コンポーネントの変更が失敗しても耐えうる、または復旧できる機能を備えている必要があります。
**期待される成果:** 変更が失敗した場合に備えて、変更に関する詳細な復旧計画を用意しています。さらに、他のワークロードコンポーネントへの潜在的な影響を最小限に抑えるために、リリースのサイズを縮小します。その結果、変更の失敗によって発生する可能性のあるダウンタイムが短縮され、復旧時間の柔軟性と効率性が向上し、ビジネスへの影響を軽減できます。
**一般的なアンチパターン:**
+ あなたがデプロイを実行したところ、アプリケーションが不安定になりましたが、システムにはアクティブなユーザーがいるように見えます。変更をロールバックしてアクティブなユーザーに影響を与えるか、または、いずれにしてもユーザーが影響を受ける可能性があることを考慮して、変更をロールバックするのを待つかを判断しなければなりません。
+ ルーティンを変更すると、新しい環境はアクセスできますが、サブネットの 1 つにアクセスできなくなります。すべてをロールバックするか、アクセスできないサブネットを修正するかを判断しなければなりません。その判断がなされるまでの間、サブネットはアクセスできないままとなります。
+ システムが、より小さなリリースで更新できるように設計されていません。その結果、デプロイが失敗した際に、これらの一括変更を取り消すことが困難になります。
+ Infrastructure as Code (IaC) を使用せず、インフラストラクチャを手動で更新してきた結果、望ましくない構成が生じます。手動変更を効果的に追跡して元に戻すことができません。
+ デプロイ頻度の増加については測定していないため、チームには変更の規模を縮小したり、変更のたびにロールバック計画を改善したりする動機付けがなされておらず、リスクも失敗率が高まることになります。
+ 変更の失敗によるシステム停止の合計時間を測定していないため、チームは、デプロイプロセスや復旧計画の効果を優先順位付けして改善することができません。
**このベストプラクティスを活用するメリット:** 変更の失敗からの復旧計画を立てることで、平均復旧時間 (MTTR) を最小限に抑え、ビジネスへの影響を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
リリースチームが一貫性のある文書化されたポリシーとプラクティスを採用することで、組織は変更が失敗した場合の対策を計画できます。このポリシーでは、特定の状況でフィックスフォワードが許可される必要があります。いずれの場合も、変更を元に戻すためにかかる時間が最小限になるよう、本番環境へのデプロイ前にフィックスフォワードまたはロールバックの計画を適切に文書化して、十分なテストを行う必要があります。
### 実装手順
1. 特定の期間内に変更を元に戻すための効果的な計画を立てることをチームに要求するポリシーを文書化します。
1. ポリシーには、フィックスフォワードが許可される状況を明記します。
1. 関係者全員が文書化されたロールバック計画にアクセスできることを必須とします。
1. ロールバックの要件 (許可されない変更がデプロイされたことが判明した場合など) を指定します。
1. ワークロードの各コンポーネントに関連するすべての変更の影響レベルを分析します。
1. 反復可能な変更が変更のポリシーを実行する一貫したワークフローに従っていれば、こうした変更の標準化、テンプレート化、事前承認が許可されるようにします。
1. 変更の規模を小さくすることで、変更による潜在的な影響を軽減し、復旧にかかる時間を短縮し、ビジネスへの影響を軽減します。
1. 可能な限りインシデントを回避するために、ロールバック手順によってコードが確実に既知の良好な状態に戻るようにします。
1. ツールとワークフローを統合して、プログラムによってポリシーを適用します。
1. 変更に関するデータを他のワークロードオーナーにも見えるようにすることで、ロールバックができない変更の失敗の診断を迅速に行えるようにします。
1. 目に見える変更データを使用することで、このプラクティスの成功を測定し、反復的な改善点を特定します。
1. モニタリングツールを使用してデプロイの成功または失敗を検証し、ロールバックに関する意思決定を加速します。
1. 変更の失敗時のシステム停止時間を測定して、復旧計画を継続的に改善します。
**実装計画に必要な工数レベル:** 中程度
## リソース
**関連するベストプラクティス:**
+ [OPS06-BP08 テストとロールバックを自動化する](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 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**関連動画:**
+ [ re:Invent 2019 \$1 Amazon’s approach to high-availability deployment ](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 デプロイをテストする
本番環境と同じデプロイ設定、セキュリティ管理、手順、プロシージャを使用して、本番稼働前にリリース手順をテストします。ファイル、設定、サービスの検査など、デプロイされたすべての手順が期待どおりに完了することを確認します。さらに、機能テスト、統合テスト、負荷テストによってすべての変更をテストして、ヘルスチェックなどのモニタリングも行います。これらのテストを行うことで、デプロイの問題を早期に特定し、本番稼働前に計画を立てて問題を軽減するよう対応できます。
すべての変更をテストするための一時的な並列環境を作成できます。Infrastructure as Code (IaC) を使用してテスト環境のデプロイを自動化することで、必要な作業量を減らし、安定性と一貫性を確保するとともに、より迅速に機能を提供できます。
**期待される成果:** 組織が、デプロイのテストを含むテスト駆動開発文化を採用します。これにより、チームはリリースの管理ではなくビジネス価値の提供に集中できます。チームはデプロイのリスクを早期に特定し、適切な緩和策を決定できます。
**一般的なアンチパターン:**
+ 未テストのデプロイで、トラブルシューティングとエスカレーションを必要とする問題が頻発します。
+ リリースには、既存のリソースを更新する Infrastructure as Code (IaC) が含まれています。IaC が正常に実行されるか、またはリソースに影響を及ぼすか確信がありません。
+ あなたは、新しい機能をアプリケーションにデプロイします。しかし、意図した通りに機能せず、影響を受けたユーザーからの報告を受けるまで問題を認識できません。
+ あなたは、証明書を更新します。証明書を間違ったコンポーネントにインストールしてしまいますが、検出はされないままです。そのため、ウェブサイトへの安全な接続が確立されず、ウェブサイトの訪問者に影響が及びます。
**このベストプラクティスを活用するメリット:** デプロイ手順とデプロイによって生じる変更を本番稼働前に十分にテストすることで、デプロイ手順による本番環境への潜在的な影響を最小限に抑えることができます。これにより、変更の提供を遅らせることなく、本番リリースでの自信が高まり、運用サポートが最小限に抑えられます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
デプロイプロセスをテストすることは、デプロイによって生じる変更をテストすることと同じくらい重要です。そのためには、本番環境にできるだけ近い本番稼働前の環境でデプロイ手順をテストします。その結果、不完全または不正確なデプロイ手順、または設定ミスなどの一般的な問題を、本番リリース前に検出できます。さらに、復旧手順をテストすることもできます。
**お客様事例**
AnyCompany Retail は、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインの一環として、インフラストラクチャとソフトウェアの更新を顧客にリリースするために必要な定義済みの手順を本番環境に似た環境で実行します。このパイプラインは、デプロイ前にリソースのドリフトを検出する (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、](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) AWS CloudTrail、Amazon SNS イベント通知を使用して、デプロイをモニタリングします。
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 Practicing Continuous Integration and Continuous Delivery on AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [ The Story of Apollo - Amazon's Deployment Engine ](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/)
+ [ Integrating Network Connectivity Testing with Infrastructure Deployment ](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**関連動画:**
+ [ re:Invent 2020 \$1 Testing software and systems at Amazon ](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**関連する例:**
+ [ Tutorial \$1 Deploy and Amazon ECS service with a validation test ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 安全なデプロイ戦略を使用する
安全な本番環境のロールアウトでは、変化による顧客への影響を最小限に抑えることを目的として、有益な変化の流れを管理します。安全管理は、期待される結果を検証し、変更やデプロイの失敗によって生じた不具合による影響の範囲を制限するための検査メカニズムを提供します。安全なロールアウトには、機能フラグ、ワンボックス、ローリング (canary リリース)、イミュータブル、トラフィック分割、ブルー/グリーンデプロイなどの戦略が含まれる場合があります。
**期待される成果:** 組織は、安全なロールアウトを自動化する機能を備えた継続的インテグレーションと継続的デリバリー (CI/CD) システムを使用します。チームは適切な安全なロールアウト戦略を使用する必要があります。
**一般的なアンチパターン:**
+ あなたは、失敗した変更を一度にすべての本稼働環境にデプロイします。その結果、すべての顧客に一斉に影響が及びます。
+ 全システムへの同時デプロイで生じた不具合により、緊急リリースが必要となります。すべての顧客への影響を修正するには数日かかります。
+ 本番リリースを管理するために、複数のチームの計画と参加が必要です。これにより、顧客のために頻繁に機能を更新する能力が制限されます。
+ あなたは、既存のシステムを変更することにより、変更可能なデプロイを実行します。変更の失敗が判明した後、あなたは、システムを再度変更して古いバージョンを復元することを強いられ、これにより復旧にかかる時間が長くなります。
**このベストプラクティスを活用するメリット:** 自動デプロイにより、ロールアウトの速度と、顧客に一貫して有益な変更を提供することのバランスを取ることができます。影響を制限することで、コストのかかるデプロイの失敗を防ぎ、チームが失敗に効率的に対応する能力を最大限に高めることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
継続的デリバリーの失敗は、サービス可用性の低下と、カスタマーエクスペリエンスの低下につながる可能性があります。デプロイの成功率を最大化するには、デプロイの失敗ゼロを目標に、エンドツーエンドのリリースプロセスに安全管理を実装してデプロイエラーを最小限に抑えます。
**お客様事例**
AnyCompany Retail は、ダウンタイムを最小限またはゼロにすることを目指しています。これは、デプロイ中に認識されるユーザーへの影響がまったくないことを意味します。これを実現するために、同社はローリングデプロイやブルー/グリーンデプロイなどのデプロイパターン (次のワークフロー図を参照) を確立しました。すべてのチームが、CI/CD パイプラインでこれらのパターンを 1 つ以上採用しています。
| Amazon EC2 の CodeDeploy ワークフロー | Amazon ECS の CodeDeploy ワークフロー | Lambda の CodeDeploy ワークフロー |
| --- | --- | --- |
| ![\[Amazon EC2 のデプロイプロセスフロー\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/images/deployment-process-ec2.png) | ![\[Amazon ECS のデプロイプロセスフロー\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/images/deployment-process-ecs.png) | ![\[Lambda のデプロイプロセスフロー\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/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 や [Amazon RDS の](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) などのデータベースでは [ブルー/グリーンデプロイを使用します](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)。
1. [Amazon CloudWatch、](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) AWS CloudTrail、Amazon SNS イベント通知を使用して、デプロイをモニタリングします。
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 Builders' Library \$1 安全なハンズオフデプロイメントの自動化 \$1 本番デプロイメント ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 My CI/CD pipeline is my release captain \$1 Safe, automatic production releases](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS ホワイトペーパー \$1 Practicing Continuous Integration and Continuous Delivery on AWS \$1 Deployment methods](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 Deployment Types](https://docs.aws.amazon.com/)
+ [Fully Managed Blue/Green Deployments in Amazon Aurora and 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 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon's Approach to high-availability deployment](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**関連する例:**
+ [AWS CodeDeploy でブルー/グリーンデプロイのサンプルを試す](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Workshop \$1 Buiding CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.us-east-1.prod.workshops.aws/workshops/5195ab7c-5ded-4ee2-a1c5-775300717f42/en-US)
+ [Workshop \$1 Blue/Green and Canary Deployment for EKS and ECS](https://catalog.us-east-1.prod.workshops.aws/workshops/2175d94a-cd79-4ed2-8e7e-1f0dd1956a3a/en-US)
+ [Workshop \$1 Building a Cross-account CI/CD Pipeline](https://catalog.us-east-1.prod.workshops.aws/workshops/00bc829e-fd7c-4204-9da1-faea3cf8bd88/en-US)
# OPS06-BP08 テストとロールバックを自動化する
デプロイプロセスの速度、信頼性、自信を高めるには、本番稼働前環境と本番環境でテストとロールバック機能を自動化する戦略を立てます。本番環境にデプロイする際のテストを自動化して、デプロイされる変更を検証する人間とシステムの操作をシミュレートします。ロールバックを自動化して、迅速に以前の既知の正常な状態に戻します。ロールバックは、変更によって望ましい結果が得られなかった場合や、自動テストが失敗した場合など、事前に定義された条件に基づいて自動的に開始する必要があります。これら 2 つのアクティビティを自動化することで、デプロイの成功率が向上し、復旧時間を最小限に抑え、ビジネスへの潜在的な影響を軽減できます。
**期待される成果:** 自動テストとロールバック戦略は、継続的インテグレーション、継続的デリバリー (CI/CD) パイプラインに統合されます。モニタリングによって、成功基準に照らして検証を行い、失敗の発生時に自動ロールバックを開始できます。これにより、エンドユーザーや顧客への影響を最小限に抑えることができます。例えば、すべてのテスト結果が期待を満たす場合は、同じテストケースを活用して、自動リグレッションテストが開始される本番環境にコードを昇格させます。リグレッションテストの結果が期待を満たさない場合、パイプラインワークフローで自動ロールバックが開始されます。
**一般的なアンチパターン:**
+ システムが、より小さなリリースで更新できるように設計されていません。その結果、デプロイが失敗した際に、これらの一括変更を取り消すことが困難になります。
+ デプロイプロセスが一連の手動のステップで構成されています。ワークロードに変更をデプロイした後に、デプロイ後のテストを開始します。テスト後、ワークロードが操作できず、顧客の接続が切断されたことに気付きます。あなたはその後、以前のバージョンへのロールバックを開始します。こうした手動の手順すべてが、システム復旧を遅らせるだけでなく、顧客への影響も長引く原因となります。
+ アプリケーションで使用頻度の低い機能に対する自動テストケースを時間をかけて構築したことで、自動テスト機能の投資利益率が最小化されています。
+ リリースには、アプリケーション、インフラストラクチャ、パッチ、および設定の更新が含まれ、これらは互いに独立しています。ただし、単一の CI/CD パイプラインを使用して、すべての変更を一度に提供しています。1 つのコンポーネントで失敗が発生すると、すべての変更を元に戻すことを強いられることになり、ロールバックが複雑で非効率なものになります。
+ あなたのチームは、スプリント 1 でコード作業を完了し、スプリント 2 の作業を開始しますが、計画にはスプリント 3 まではテストが含まれていません。その結果、自動テストによって、スプリント 2 の成果物のテストを開始する前に解決が必要な障害がスプリント 1 で検出されたため、リリース全体が遅れ、あなたの自動テストの評価が下がってしまいます。
+ 本番リリースに対する自動リグレッションテストケースは完了していますが、ワークロードの状態はモニタリングしていません。サービスが再起動したかどうかを確認できないため、あなたはロールバックが必要なのか、ロールバックが実行済みなのかがわかりません。
**このベストプラクティスを活用するメリット:** 自動テストにより、テストプロセスの透明性が高まり、さらに短い期間でより多くの機能をカバーできるようになります。本番環境での変更をテストして検証することで、即座に問題を特定できます。自動テストツールとの整合性が向上すると、不具合の検出も向上します。以前のバージョンに自動的にロールバックすることで、顧客への影響を最小限に抑えることができます。自動ロールバックによってビジネスへの影響が軽減し、デプロイ機能の信頼性が高まります。全体的に、これらの機能によって品質を確保しながら納期を短縮できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
デプロイした環境のテストを自動化し、望ましい結果をよりすばやく確認します。事前に定義された結果が達成されない場合に以前の既知の正常な状態に自動的にロールバックすることで、復旧時間を最小限に抑えるとともに、手動プロセスによるエラーを減らします。テストツールをパイプラインワークフローと統合することで、一貫したテストを行い、手動入力を最小限に抑えます。最大のリスクを軽減し、変更のたびに頻繁にテストする必要があるようなテストケースの自動化を優先します。さらに、テスト計画で事前に定義されている特定の条件に基づいてロールバックを自動化します。
### 実装手順
1. 要件の計画から、テストケースの作成、ツールの設定、自動テスト、テストケースの完了に至る、テストプロセスのあらゆる段階を定義する、開発ライフサイクルのテストライフサイクルを確立します。
1. 全体的なテスト戦略から、ワークロード固有のテストアプローチを作成します。
1. 開発ライフサイクル全体を通じて、必要に応じて継続的なテスト戦略を検討します。
1. ビジネス要件とパイプラインへの投資に基づいて、テストとロールバック向けの自動ツールを選択します。
1. どのテストケースを自動化し、どのテストケースを手動で実行するかを決めます。これは、テスト対象の機能に対するビジネス価値の優先順位に基づいて定義できます。チームメンバー全員にこの計画を浸透させて、手動テストを実施する責任を確認します。
1. 反復可能なケースや頻繁に実行されるケース、反復的なタスクが必要なケース、複数の構成で必要なケースなど、自動化に適した特定のテストケースに自動テスト機能を適用します。
1. 自動化ツールでテスト自動化スクリプトと成功基準を定義して、特定のケースが失敗した場合に継続的なワークフローの自動化が開始されるようにします。
1. 自動ロールバックの具体的な失敗基準を定義します。
1. テスト自動化を優先させ、複雑さと人間の操作によって失敗のリスクが高まる部分で、綿密なテストケースにより一貫した結果が達成されるようにします。
1. 自動テストツールとロールバックツールを CI/CD パイプラインに統合します。
1. 変更の明確な成功基準を策定します。
1. モニタリングと観察によってこうした基準を検出し、特定のロールバック基準を満たす場合は自動的に変更を元に戻します。
1. 次のようなさまざまなタイプの自動の本番環境テストを実施します。
1. 2 つのユーザーテストグループ間の現在のバージョンとの比較結果を示す A/B テスト。
1. すべてのユーザーにリリースする前に、変更を一部のユーザーにロールアウトできる canary テスト。
1. アプリケーションの外部から新しいバージョンの機能に一度に 1 つずつフラグを付け/外し、新しい機能を 1 つずつ検証することが可能な機能フラグテスト。
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/)
+ [Redeploy and rollback a deployment with AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [ 8 best practices when automating your deployments with AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**関連する例:**
+ [ Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)
**関連動画:**
+ [ re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon ](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [ re:Invent 2019 \$1 Amazon's Approach to high-availability deployment ](https://www.youtube.com/watch?v=bCgD2bX1LI4)