# 開発とデプロイのプロセス
<a name="a-sus-development-deployment"></a>

**Topics**
+ [SUS 6 開発およびデプロイのプロセスは、持続可能性目標を目指すうえでどのように役立ちますか?](w2aac19c15c15b5.md)

# SUS 6 開発およびデプロイのプロセスは、持続可能性目標を目指すうえでどのように役立ちますか?
<a name="w2aac19c15c15b5"></a>

開発、テスト、デプロイのプラクティスを変更することで、持続可能性に対する影響を減らす機会を探します。 

 ベストプラクティス: 

# SUS06-BP01 持続可能性の改善を迅速に導入できる方法を採用する
<a name="sus_sus_dev_a2"></a>

 本稼働環境にデプロイする前に、潜在的な改善をテストして検証します。改善に際して将来的に起こりうる利点を計算する際のテストにかかるコストを考慮します。低コストのテスト方法を開発し、小規模な改善を実施します。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  持続可能性の要件を開発プロセスに追加します。 
+  持続可能性の改善策を開発、テスト、デプロイするために、リソースを並行して働かせることができるようにします。 
+  本稼働環境にデプロイする前に、持続可能性に対する影響をもたらしうる改善をテストして検証します。 
+  最小限に実行可能である代表的なコンポーネントを使用して、潜在的な改善をテストします。 
+  テスト済みの持続可能性の改善が利用可能になったら本番環境にデプロイします。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS enables sustainability solutions (AWS が実現するサステナビリティソリューション)](https://aws.amazon.com/sustainability/) 

 **関連する例:** 
+  [ラボ: ](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) コストと使用状況レポートを効率性レポートに変える 

# SUS06-BP02 ワークロードを最新に保つ
<a name="sus_sus_dev_a3"></a>

 最新のオペレーティングシステム、ライブラリ、およびアプリケーションを使用すると、ワークロードの効率が上がり、さらに効率的なテクノロジーを簡単に導入できます。最新のソフトウェアにはまた、ワークロードの持続可能性に対する影響をより正確に測定する機能が含まれている場合があります。これは、ベンダーが独自の持続可能性の目標を満たすための機能でもあります。 

 **一般的なアンチパターン:** 
+  現在のアーキテクチャは、時間が経つと更新されずに静的なものになると想定している。 
+  更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的なミーティングがない。 
+  あなたは、理由なしで、時間の経過とともにアーキテクチャの変更を導入します。 

 **このベストプラクティスを活用するメリット:** ワークロードを最新に保つプロセスを確立することで、新しい機能と能力を採用し、問題を解決し、ワークロードの効率性を高めることができます。

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ワークロードに応じた新しい機能やインスタンスを評価するプロセスとスケジュールを定義します。クラウドの俊敏性を利用して、新しい機能がワークロードをどのように改善するかをすばやくテストします。 
  +  持続可能性への影響を削減する。 
  +  パフォーマンスの効率を高める。 
  +  計画した改善にとっての障壁を取り除く。 
  +  持続可能性に対する影響の測定能力と管理能力を高める。 
+  ワークロードソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する。専用のインフラストラクチャで [AWS Systems Manager インベントリ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) を使用して、Amazon EC2 インスタンスからオペレーティングシステム (OS)、アプリケーション、インスタンスのメタデータを収集し、どのインスタンスがソフトウェアポリシーで要求されるソフトウェアと設定を実行しているか、どのインスタンスがアップデートする必要があるかを迅速に把握することが可能です。 
+  ワークロードのコンポーネントを更新する方法を理解します。 
  +  Linux または Windows サーバーイメージ向けの [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) の更新を管理するには、以下を使用します [EC2 Image Builder](https://aws.amazon.com/image-builder/). 
  +  既存のパイプラインで [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) を使用して、 [Amazon Elastic Container Service (Amazon ECS) イメージの管理と](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) と [Amazon Elastic Kubernetes Service イメージの管理ができます。](https://docs.aws.amazon.com/=AmazonECR/latest/userguide/ECR_on_EKS.html) 
  +  AWS Lambda には、 [バージョン管理機能が含まれています。](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) 
+  更新プロセスにオートメーションを使用して、新しい機能をデプロイする労力のレベルを軽減し、手動プロセスに起因するエラーを抑制します。例えば [AWS Systems Manager パッチマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) などのツールを使用して、システム更新のプロセスを自動化し、 [AWS Systems Manager メンテナンスウィンドウを使用してアクティビティをスケジューリングします](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS アーキテクチャセンター](https://aws.amazon.com/architecture) 
+  [AWS の最新情報](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected) 
+  [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/) 
+  [AWS Systems Manager パッチマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 

 **関連する例:** 
+  [Well-Architected ラボ: インベントリおよびパッチ管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) 
+  [ラボ: AWS Systems Manager](https://mng.workshop.aws/ssm.html) 

# SUS06-BP03 ビルド環境の利用率を高める
<a name="sus_sus_dev_a4"></a>

 オートメーションと Infrastructure as Code を使用して、必要に応じて本番稼働前の環境を起動し、使用しないときは停止します。一般的なパターンとしては、開発チームのメンバーの勤務時間と重なるように可用性期間のスケジュールを設定することがあります。休止は、状態を維持し、必要なときにのみインスタンスを迅速にオンラインにする便利な手段です。バーストキャパシティ、スポットインスタンス、伸縮自在なデータベースサービス、コンテナ、その他のテクノロジーを備えたインスタンスタイプ使用して、開発およびテストのキャパシティを使用に合わせて調整します。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  オートメーションを使用して、開発環境とテスト環境を最大限に活用します。 
+  オートメーションを使用して開発環境とテスト環境のライフサイクルを管理します。 
+  最小限に実行可能である代表的な環境を使用して、潜在的な改善を開発およびテストします。 
+  オンデマンドインスタンスを使用してデベロッパーのデバイスを支給します。 
+  オートメーションを使用して、ビルドリソースの効率を最大化します。 
+  バーストキャパシティ、スポットインスタンス、その他のテクノロジーを備えたインスタンスタイプを使用して、ビルドキャパシティを使用状況に合わせて調整します。 
+  要塞ホストのフリートをデプロイするのではなく、ネイティブなクラウドサービスを採用して、インスタンスシェルのアクセスを保護します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 
+  [Amazon EC2 バーストパフォーマンスインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) 
+  [AWS CloudFormation とは?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 

# SUS06-BP04 マネージド型 Device Farm を使用してテストする
<a name="sus_sus_dev_a5"></a>

 マネージド型の Device Farm は、ハードウェアの製造やリソースの使用の持続可能性に対する影響を複数のテナントに分散させます。マネージド型 Device Farm は、さまざまなデバイスタイプを提供するため、あまり使われない古いハードウェアをサポートすることで、不要なデバイスのアップグレードによるお客様の持続可能性に対する影響を回避できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 マネージド型 Device Farm を代表的なハードウェアセットと共に使用してテストを行い、変更の影響を理解して、サポート対象のデバイスを最大化する開発を繰り返します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Device Farm とは?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)