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

​
ベストプラクティス

どのような方法でデプロイ自動化を構成する場合でも、デプロイ前に rules、custom DB scripts、hooks の単体テストを行い、さらにデプロイ後にはテナントに対していくつかの統合テストも実行することをお勧めします。詳細については、Quality Assurance ガイダンスを参照してください。
Auth0 では、デプロイ自動化の方法としていくつかの異なる選択肢をサポートしており、必要に応じてそれぞれを組み合わせて使用することもできます。
  • Auth0 Deploy CLI tooling では、既存の Continuous Integration/Continuous Deployment (CI/CD) パイプラインとの統合に役立つ、使いやすいスクリプトが提供されています。
  • CI/CD パイプラインと直接統合できない場合、または何らかの理由で CI/CD パイプラインがない場合は、Auth0 の Source Control Extensions を使うことで、設定が簡単で保守負担の非常に少ない基本的な自動化プロセスを実現できます。
Deploy CLI Tool と source control extensions はどちらも破壊的な変更を引き起こす可能性がある点に注意してください。自動デプロイの合間に Dashboard で直接行った手動変更は失われる可能性があります。そのため、いずれかを使用する場合は、すべての変更をツール経由で参照される source control サブシステムからデプロイし、手動で変更しないようにする必要があります。
各環境では、環境固有の構成も必要になる場合があります。たとえば、Application の や は Auth0 テナントごとに異なります。そのため、値をハードコードするのではなく、これらを動的に参照できる方法が必要になります。Auth0 では、環境固有の構成情報を扱うために、次の 2 つの方法のいずれかをサポートしています。
  • Tenant Specific Variables を使用する
  • Auth0 Deploy CLI tool を使用している場合は keyword replacement を使用する

​
テナント固有の変数

Auth0 では、カスタム拡張機能内から利用できる変数を設定できます。これらは、Auth0 テナント向けの環境変数のようなものです。開発、テスト、本番の各環境間でコードを移すたびに変わる参照をハードコーディングする代わりに、テナントで設定した変数名を使い、それをカスタム拡張コードから参照できます。これにより、実行時にテナント固有の値が変数に設定されるため、同じカスタムコードを変更せずに異なるテナントで利用しやすくなります。
  • Actions での変数の使用については、エディターでシークレットを設定する方法を説明した Write Your First Action を参照してください
  • Rules での変数の使用については、値の設定方法を参照してください
  • Hooks での変数の使用については、エディターでシークレットを設定する方法を参照してください
  • Custom DB Scripts での変数の使用については、設定パラメーターを参照してください

​
ベストプラクティス

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

​
プロジェクト計画ガイド

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