> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Auth0 のツールがテナントのデプロイ自動化にどのように役立つか。

# デプロイ自動化 (B2C)

変更管理と [QA](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/quality-assurance) のベストプラクティスを取り入れることに加えて、成功している顧客は、自動デプロイプロセスの一部として Auth0 の構成資産管理も統合しています。[SDLC support](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/architecture#sdlc-support) の Architecture セクションで説明しているように、開発、テスト、本番の各環境にそれぞれ別個の Auth0 テナントを用意し、各環境のテナント構成がほぼ同一になるようにするのが望ましいです。デプロイ自動化を利用すると、各環境のテナントを同じように構成しやすくなり、環境間の構成の不一致が原因で不具合が発生する可能性を低くできます。

<Info>
  ### ベストプラクティス

  どのような方法でデプロイ自動化を構成する場合でも、デプロイ前に rules、custom DB scripts、hooks の単体テストを行い、さらにデプロイ後にはテナントに対していくつかの統合テストも実行することをお勧めします。詳細については、[Quality Assurance](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/quality-assurance) ガイダンスを参照してください。
</Info>

Auth0 では、デプロイ自動化の方法としていくつかの異なる選択肢をサポートしており、必要に応じてそれぞれを組み合わせて使用することもできます。

* [Auth0 Deploy CLI tooling](/docs/ja-jp/deploy-monitor/deploy-cli-tool) では、既存の Continuous Integration/Continuous Deployment (CI/CD) パイプラインとの統合に役立つ、使いやすいスクリプトが提供されています。
* CI/CD パイプラインと直接統合できない場合、または何らかの理由で CI/CD パイプラインがない場合は、Auth0 の [Source Control Extensions](/docs/ja-jp/customize/extensions) を使うことで、設定が簡単で保守負担の非常に少ない基本的な自動化プロセスを実現できます。

<Warning>
  Deploy CLI Tool と source control extensions はどちらも破壊的な変更を引き起こす可能性がある点に注意してください。自動デプロイの合間に Dashboard で直接行った手動変更は失われる可能性があります。そのため、いずれかを使用する場合は、**すべての**変更をツール経由で参照される source control サブシステムからデプロイし、手動で変更しないようにする必要があります。
</Warning>

各環境では、環境固有の構成も必要になる場合があります。たとえば、Application の <Tooltip tip="Client ID: Auth0 から登録済みリソースに付与される識別値。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Client+ID">Client ID</Tooltip> や <Tooltip tip="Client Secret: クライアント（アプリケーション）が Authorization Server で認証するために使用する秘密情報。これはクライアントと Authorization Server のみが知っているべきであり、推測されないよう十分にランダムでなければなりません。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Client+Secrets">Client Secrets</Tooltip> は Auth0 テナントごとに異なります。そのため、値をハードコードするのではなく、これらを動的に参照できる方法が必要になります。Auth0 では、環境固有の構成情報を扱うために、次の 2 つの方法のいずれかをサポートしています。

* [Tenant Specific Variables](#tenant-specific-variables) を使用する
* Auth0 Deploy CLI tool を使用している場合は keyword replacement を使用する

<div id="tenant-specific-variables">
  ## テナント固有の変数
</div>

Auth0 では、カスタム[拡張機能](/docs/ja-jp/customize/extensions)内から利用できる変数を設定できます。これらは、Auth0 テナント向けの環境変数のようなものです。開発、テスト、本番の各環境間でコードを移すたびに変わる参照をハードコーディングする代わりに、テナントで設定した変数名を使い、それをカスタム拡張コードから参照できます。これにより、実行時にテナント固有の値が変数に設定されるため、同じカスタムコードを変更せずに異なるテナントで利用しやすくなります。

* Actions での変数の使用については、エディターでシークレットを設定する方法を説明した [Write Your First Action](/docs/ja-jp/customize/actions/write-your-first-action) を参照してください
* Rules での変数の使用については、[値の設定方法](/docs/ja-jp/customize/rules/configuration)を参照してください
* Hooks での変数の使用については、エディターで[シークレット](/docs/ja-jp/customize/hooks/hook-secrets)を設定する方法を参照してください
* Custom DB Scripts での変数の使用については、[設定パラメーター](/docs/ja-jp/authenticate/database-connections/custom-db/create-db-connection#step-3-add-configuration-parameters)を参照してください

<Info>
  ### ベストプラクティス

  テナント固有の値だけでなく、カスタムコード内に公開すべきでない機密性の高いシークレットを保持するためにも、変数を使用することを推奨します。カスタムコードを GitHub/GitLab/Bitbucket/VSTS にデプロイしている場合、テナント固有の変数を使うことで、リポジトリ経由で機密値が露出するのを防げます。
</Info>

<div id="project-planning-guide">
  ## プロジェクト計画ガイド
</div>

推奨戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドを提供しています。

[B2C IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)