- それぞれの環境（開発、ステージング、運用）に個別のAuth0テナントを作成します。
- 1つのリポジトリを作成して、すべての環境のリソース構成ファイルを含めます。
- CI/CDパイプラインに手順を追加して、環境へのデプロイ時に、Auth0のリソース構成が適切なAuth0テナントに適用されるようにします。
環境のテナント
それぞれの環境には、Auth0のテナントやアカウントを個別にすることをお勧めします。例：| 環境 | テナント |
|---|---|
| 開発 | travel0-dev |
| テスト | travel0-uat |
| ステージング | travel0-stage |
| 運用 | travel0-prod |
リソース構成リポジトリ
エクスポートすると、Auth0テナントの状態がリソース構成ファイルのセットとして、YAMLまたはディレクトリ形式で表されます。環境が複数あるコンテキストでは、すべての環境に適用される1つのリソース構成リポジトリの存在が予期されます。実際には、これはプロジェクトのコードベース内のディレクトリや、全く別のコードベース内であったりするかもしれません。 デプロイすることなく変更が行えるように、それぞれのテナントにはリポジトリ内に少なくとも1つのブランチが必要です。そうすれば、作業ブランチがプライマリーブランチ（mainやmasterなど）と結合するときにのみ、変更がデプロイされます。このセットアップでは、それぞれの環境に継続した統合タスクを使用して、プライマリーブランチが更新を受け取ると、対象環境へ自動的に変更をデプロイできます。
ワークフローはおそらく以下のようになります。
- 開発環境で変更を行います。
- テスト環境（またはuat）で変更を結合します。
- ユーザー受け入れテスト（uat）への変更をテストします。準備が整ったら、変更をステージング環境に移動して結合します。
- ステージング環境でテストします。準備が整ったら、変更を運用環境に移動して結合します。
単一方向フロー
複数環境のワークフローは、変更を単一方向で上へと伝播させる場合に最適です。リソース構成ファイルへの変更は、まず最も低い環境（開発など）に適用してから、徐々に上へと進めて他の全環境に適用し、最終的には運用環境に適用します。この単一方向の進め方は、テナントへの変更に十分なテストと評価を行えるようにします。設定したら、後続のDeploy CLIのエクスポートによって変更が取得されない限り、やなど、他の手段で直接構成を運用環境に適用しないことをお勧めします。そうしないと、それらの変更が上書きされる可能性があります。環境に特有の値
すべての環境には同じリソース構成ファイルのセットが共有されますが、環境に特有の値は、個別のツール構成ファイルや動的なキーワード置換を使って表現することができます。個別の構成ファイル
それぞれの環境に個別のツール構成ファイルを指定すると、リソース構成ファイルを環境に依存することなく使用しながら、それぞれの環境に必要な対応を提供できます。それぞれの環境には少なくとも個別の資格情報が必要になりますが、それぞれの環境について、特定のリソースを除外したり、削除の有効化や動的なキーワード置換を行ったりできます。ファイル構造の例
キーワード置換の動的値
それぞれの環境に個別の構成ファイルが適用されると、キーワード置換にAUTH0_KEYWORD_REPLACE_MAPPINGS構成プロパティを使用して、環境に応じた動的な代替値を表現することができます。たとえば、クライアントについて、許可されているオリジンのセットを分ける必要がある場合などです。詳細については、「キーワードの置換」をお読みください。