翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# DevOps 環境について


分岐戦略を理解するには、各環境で発生する目的とアクティビティを理解する必要があります。複数の環境を確立することで、開発アクティビティをステージに分割し、それらのアクティビティをモニタリングし、未承認機能の意図しないリリースを防ぐことができます。 AWS アカウント 各環境に 1 つ以上の を持つことができます。

ほとんどの組織には、いくつかの使用環境が概説されています。ただし、環境の数は組織やソフトウェア開発ポリシーによって異なる場合があります。このドキュメントシリーズでは、開発パイプラインにまたがる次の 5 つの一般的な環境があることを前提としていますが、異なる名前で呼び出される場合があります。
+ **サンドボックス** – デベロッパーがコードを記述し、間違いを犯し、概念実証作業を実行する環境。
+ **開発** – 開発者がコードを統合して、すべてが単一のまとまりのあるアプリケーションとして動作することを確認する環境。
+ **テスト** – QA チームまたは承認テストが行われる環境。多くの場合、チームはこの環境でパフォーマンステストや統合テストを行います。
+ **ステージング** – 本番稼働前の環境で、本番稼働と同等の状況でコードとインフラストラクチャが期待どおりに動作することを検証します。この環境は、本番環境とできるだけ類似するように設定されています。
+ **本番**稼働 – エンドユーザーと顧客からのトラフィックを処理する環境。

このセクションでは、各環境について詳しく説明します。また、各環境のビルドステップ、デプロイステップ、終了基準についても説明し、次の段階に進むことができます。次の図は、これらの環境を順番に示しています。

![\[一般的な DevOps 環境の順番\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/choosing-git-branch-approach/images/devops-environments.png)


**Topics**
+ [

# サンドボックス環境
](sandbox-environment.md)
+ [

# デベロッパー環境
](development-environment.md)
+ [

# 環境のテスト
](testing-environment.md)
+ [

# ステージング環境
](staging-environment.md)
+ [

# 本番環境
](production-environment.md)

# サンドボックス環境


*サンドボックス環境*は、デベロッパーがコードを記述し、間違いを犯し、概念実証作業を実行する場所です。サンドボックス環境にデプロイするには、ローカルワークステーションから、またはローカルワークステーションのスクリプトを使用します。

## アクセス


開発者はサンドボックス環境へのフルアクセスを持っている必要があります。

## ビルドステップ


開発者は、サンドボックス環境に変更をデプロイする準備ができたら、ローカルワークステーションでビルドを手動で実行します。

1. [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) を使用して機密情報をスキャンする

1. ソースコードをリントする

1. 該当する場合は、ソースコードを構築してコンパイルします。

1. ユニットテストを実行する

1. コードカバレッジ分析を実行する

1. 静的コード分析を行う

1. Infrastructure as Code (IaC) を構築する

1. IaC セキュリティ分析を実行する

1. オープンソースライセンスを抽出する

1. ビルドアーティファクトを発行する

## デプロイ手順


Gitflow モデルまたは Trunk モデルを使用している場合、`feature`ブランチがサンドボックス環境で正常に構築されると、デプロイステップが自動的に開始されます。GitHub Flow モデルを使用している場合は、以下のデプロイステップを手動で実行します。サンドボックス環境のデプロイ手順は次のとおりです。

1. 公開されたアーティファクトをダウンロードする

1. データベースのバージョニングを実行する

1. IaC デプロイを実行する

1. 統合テストを実行する

## 開発環境に移行する前の期待

+ サンドボックス環境で`feature`ブランチを正常に構築する
+ デベロッパーがサンドボックス環境でこの機能を手動でデプロイしてテストした

# デベロッパー環境


*開発環境*では、デベロッパーがコードを統合して、すべてを 1 つのまとまりのあるアプリケーションとして動作させます。Gitflow では、開発環境にはマージリクエストに含まれる最新の機能が含まれており、リリースの準備が整います。GitHub フローおよびトランク戦略では、開発環境はテスト環境と見なされ、コードベースは不安定で本番環境へのデプロイに適していない可能性があります。

## アクセス


最小特権の原則に従ってアクセス許可を割り当てます。*最小特権*は、タスクの実行に必要な最小限のアクセス許可を付与するというセキュリティのベストプラクティスです。開発者は、サンドボックス環境よりも開発環境へのアクセスが少なくなければなりません。

## ビルドステップ


`develop` ブランチ (Gitflow) または`main`ブランチ (Trunk または GitHub Flow) へのマージリクエストを作成すると、ビルドが自動的に開始されます。

1. [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) を使用して機密情報をスキャンする

1. ソースコードをリントする

1. 該当する場合は、ソースコードを構築してコンパイルします。

1. ユニットテストを実行する

1. コードカバレッジ分析を実行する

1. 静的コード分析を行う

1. ビルド IaC

1. IaC セキュリティ分析を実行する

1. オープンソースライセンスを抽出する

## デプロイ手順


Gitflow モデルを使用している場合、`develop`ブランチが開発環境で正常に構築されると、デプロイステップが自動的に開始されます。GitHub フローモデルまたはトランクモデルを使用している場合、`main`ブランチに対してマージリクエストが作成されると、デプロイステップが自動的に開始されます。開発環境のデプロイ手順は次のとおりです。

1. ビルドステップから公開されたアーティファクトをダウンロードする

1. データベースのバージョニングを実行する

1. IaC デプロイを実行する

1. 統合テストを実行する

## テスト環境に移行する前の期待

+ 開発環境における`develop`ブランチ (Gitflow) または`main`ブランチ (Trunk または GitHub Flow) のビルドとデプロイの成功
+ ユニットテストが 100% で合格
+ IaC ビルドの成功
+ デプロイアーティファクトが正常に作成されました
+ 開発者が手動検証を実行して、機能が期待どおりに機能していることを確認します。

# 環境のテスト


品質保証 (QA) 担当者は、テスト環境を使用して機能を検証します。テストが終了した後、変更を承認します。承認されると、ブランチは次の環境、ステージングに移行します。Gitflow では、この環境とその上の環境は`release`ブランチからのデプロイでのみ使用できます。`release` ブランチは、計画された機能を含む`develop`ブランチに基づいています。

## アクセス


最小特権の原則に従ってアクセス許可を割り当てます。開発者は、開発環境よりもテスト環境へのアクセスが少なくなければなりません。QA 担当者には、機能をテストするための十分なアクセス許可が必要です。

## ビルドステップ


この環境のビルドプロセスは、Gitflow 戦略を使用する場合のバグ修正にのみ適用されます。`bugfix` ブランチへのマージリクエストを作成すると、ビルドが自動的に開始されます。

1. [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) を使用して機密情報をスキャンする

1. ソースコードをリントする

1. 該当する場合は、ソースコードを構築してコンパイルします。

1. ユニットテストを実行する

1. コードカバレッジ分析を実行する

1. 静的コード分析を行う

1. ビルド IaC

1. IaC セキュリティ分析を実行する

1. オープンソースライセンスを抽出する

## デプロイ手順


開発環境にデプロイした後、テスト環境で`release`ブランチ (Gitflow) または`main`ブランチ (Trunk または GitHub Flow) のデプロイを自動的に開始します。テスト環境でのデプロイ手順は次のとおりです。

1. `release` ブランチ (Gitflow) または`main`ブランチ (Trunk または GitHub Flow) をテスト環境にデプロイする

1. 指定された担当者による手動承認のために一時停止する

1. 公開されたアーティファクトをダウンロードする

1. データベースのバージョニングを実行する

1. IaC デプロイを実行する

1. 統合テストを実行する

1. パフォーマンステストを実行する

1. 品質保証の承認

## ステージング環境に移行する前の期待

+ 開発チームと QA チームは、組織の要件を満たすのに十分なテストを実施しました。
+ 開発チームは、`bugfix`ブランチを通じて検出されたバグを解決しました。

# ステージング環境


*ステージング環境*は、本番環境と同じになるように設定されています。たとえば、データ設定の範囲とサイズは本番ワークロードと類似している必要があります。ステージング環境を使用して、コードとインフラストラクチャが期待どおりに動作することを確認します。この環境は、プレビューや顧客デモなどのビジネスユースケースにも推奨されます。

## アクセス


最小特権の原則に従ってアクセス許可を割り当てます。開発者は、本番環境と同じステージング環境にアクセスできる必要があります。

## ビルドステップ


なし。テスト環境で使用されたものと同じアーティファクトがステージング環境で再利用されます。

## デプロイ手順


テスト環境での承認とデプロイ後、ステージング環境で`release`ブランチ (Gitflow) または`main`ブランチ (Trunk または GitHub Flow) のデプロイを自動的に開始します。ステージング環境でのデプロイ手順は次のとおりです。

1. `release` ブランチ (Gitflow) または`main`ブランチ (Trunk または GitHub Flow) をステージング環境にデプロイする

1. 指定された担当者による手動承認のために一時停止する

1. 公開されたアーティファクトをダウンロードする

1. データベースのバージョニングを実行する

1. IaC デプロイを実行する

1. (オプション) 統合テストを実行する

1. (オプション) 負荷テストを実行する

1. 必要な開発、QA、製品、またはビジネス承認者から承認を得る

## 本番環境に移行する前の期待

+ 本番環境と同等のリリースがステージング環境に正常にデプロイされました
+ (オプション) 統合と負荷テストが成功しました

# 本番環境


*実稼働環境*は、リリースされた製品をサポートし、実際のクライアントによって実際のデータを処理します。これは、最小特権でアクセスが割り当てられた保護された環境であり、昇格されたアクセスは、監査された例外プロセスを通じてのみ一定期間許可する必要があります。

## アクセス


本番環境では、デベロッパーは AWS マネジメントコンソールでの読み取り専用アクセスが制限されている必要があります。たとえば、デベロッパーはday-to-dayのログデータにアクセスできる必要があります。本番環境へのすべてのリリースは、デプロイ前に承認ステップでゲートする必要があります。

## ビルドステップ


なし。テスト環境とステージング環境で使用されたものと同じアーティファクトが本番環境で再利用されます。

## デプロイ手順


承認後、本番環境で`release`ブランチ (Gitflow) または`main`ブランチ (Trunk または GitHub Flow) のデプロイを自動的に開始し、ステージング環境にデプロイします。以下は、本番環境でのデプロイ手順です。

1. `release` ブランチ (Gitflow) または`main`ブランチ (Trunk または GitHub Flow) を本番環境にデプロイする

1. 指定された担当者による手動承認のために一時停止する

1. 公開されたアーティファクトをダウンロードする

1. データベースのバージョニングを実行する

1. IaC デプロイを実行する