> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-fix-docs-5528-php-updates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 複数環境のワークフローに組み込む

> Auth0 Deploy CLIを使用して、複数のテナントと複数の環境があるワークフローに対応する方法を説明します。

Deploy CLIはテナントと環境が複数あるコンテキスト内での動作に対応しています。CI/CDの開発ワークフローに統合すると、Auth0での変更内容を機能の開発から運用までの全般に反映させることができます。

一般的には以下のワークフローをお勧めします。

1. それぞれの環境（開発、ステージング、運用）に個別のAuth0テナントを作成します。
2. 1つのリポジトリを作成して、すべての環境のリソース構成ファイルを含めます。
3. CI/CDパイプラインに手順を追加して、環境へのデプロイ時に、Auth0のリソース構成が適切なAuth0テナントに適用されるようにします。

## 環境のテナント

それぞれの環境には、Auth0のテナントやアカウントを個別にすることをお勧めします。例：

| 環境     | テナント            |
| ------ | --------------- |
| 開発     | `travel0-dev`   |
| テスト    | `travel0-uat`   |
| ステージング | `travel0-stage` |
| 運用     | `travel0-prod`  |

## リソース構成リポジトリ

エクスポートすると、Auth0テナントの状態がリソース構成ファイルのセットとして、[YAMLまたはディレクトリ形式](/docs/ja-jp/deploy-monitor/deploy-cli-tool/available-resource-configuration-formats)で表されます。環境が複数あるコンテキストでは、すべての環境に適用される1つのリソース構成リポジトリの存在が予期されます。実際には、これはプロジェクトのコードベース内のディレクトリや、全く別のコードベース内であったりするかもしれません。

デプロイすることなく変更が行えるように、それぞれのテナントにはリポジトリ内に少なくとも1つのブランチが必要です。そうすれば、作業ブランチがプライマリーブランチ（`main`や`master`など）と結合するときにのみ、変更がデプロイされます。このセットアップでは、それぞれの環境に継続した統合タスクを使用して、プライマリーブランチが更新を受け取ると、対象環境へ自動的に変更をデプロイできます。

ワークフローはおそらく以下のようになります。

1. 開発環境で変更を行います。
2. テスト環境（またはuat）で変更を結合します。
3. ユーザー受け入れテスト（uat）への変更をテストします。準備が整ったら、変更をステージング環境に移動して結合します。
4. ステージング環境でテストします。準備が整ったら、変更を運用環境に移動して結合します。

予防措置として、手動でトリガーした場合にのみデプロイするように、運用環境を設定しておくことをお勧めします。

## 単一方向フロー

複数環境のワークフローは、変更を単一方向で上へと伝播させる場合に最適です。リソース構成ファイルへの変更は、まず最も低い環境（開発など）に適用してから、徐々に上へと進めて他の全環境に適用し、最終的には運用環境に適用します。この単一方向の進め方は、テナントへの変更に十分なテストと評価を行えるようにします。設定したら、後続のDeploy CLIのエクスポートによって変更が取得されない限り、<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=auth0-dashboard" tip="Auth0 Dashboard: サービスを構成するためのAuth0の主製品。" cta="用語集の表示">Auth0 Dashboard</Tooltip>や<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=management-api" tip="Management API: 顧客が管理タスクを実行できるようにするための製品。" cta="用語集の表示">Management API</Tooltip>など、他の手段で直接構成を運用環境に適用しないことをお勧めします。そうしないと、それらの変更が上書きされる可能性があります。

## 環境に特有の値

すべての環境には同じリソース構成ファイルのセットが共有されますが、環境に特有の値は、個別のツール構成ファイルや動的な[キーワード置換](/docs/ja-jp/deploy-monitor/deploy-cli-tool/keyword-replacement)を使って表現することができます。

## 個別の構成ファイル

それぞれの環境に個別のツール構成ファイルを指定すると、リソース構成ファイルを環境に依存することなく使用しながら、それぞれの環境に必要な対応を提供できます。それぞれの環境には少なくとも個別の資格情報が必要になりますが、それぞれの環境について、特定のリソースを除外したり、削除の有効化や動的なキーワード置換を行ったりできます。

### ファイル構造の例

```lines theme={null}
project-root
│
└───auth0
│   │   config-dev.json   # Dev env config file
│   │   config-test.json  # Test env config file
│   │   config-prod.json  # Prod env config file
│   │   ... all other resource configuration files
│
└───src
    │   ... your project code
```

## キーワード置換の動的値

それぞれの環境に個別の構成ファイルが適用されると、キーワード置換に`AUTH0_KEYWORD_REPLACE_MAPPINGS`構成プロパティを使用して、環境に応じた動的な代替値を表現することができます。たとえば、クライアントについて、許可されているオリジンのセットを分ける必要がある場合などです。詳細については、「[キーワードの置換](/docs/ja-jp/deploy-monitor/deploy-cli-tool/keyword-replacement)」をお読みください。

### config-dev.jsonの例

```json lines theme={null}
{
  "AUTH0_DOMAIN": "travel0-dev.us.auth0.com",
  "AUTH0_CLIENT_ID": "PdwQpGy62sHcsV6ufZNEVrV4GDlDhm74",
  "AUTH0_ALLOW_DELETE": true,
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "ENV": "dev",
    "ALLOWED_ORIGINS": ["http://localhost:3000", "http://dev.travel0.com"]
  }
}
```

### config-prod.jsonの例

```json lines theme={null}
{
  "AUTH0_DOMAIN": "travel0.us.auth0.com",
  "AUTH0_CLIENT_ID": "vZCEFsDYzXc1x9IomB8dF185e4cdVah5",
  "AUTH0_ALLOW_DELETE": false,
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "ENV": "prod",
    "ALLOWED_ORIGINS": ["http://travel0.com"]
  }
}
```