メインコンテンツへスキップ
変更管理と QA のベストプラクティスを採用することに加えて、成功しているお客様は、自動化されたデプロイプロセスの一環として Auth0 の構成管理も統合しています。アーキテクチャセクションの SDLC support で説明しているように、開発、テスト、本番の各環境には個別の Auth0 テナントを設定し、それぞれの環境のテナント設定をできる限り同一にしておく必要があります。デプロイ自動化を利用すると、各環境のテナントを同じように設定しやすくなり、環境間の設定不一致が原因でバグが発生する可能性を低減できます。

ベストプラクティス

デプロイ自動化をどのように構成する場合でも、デプロイ前に Rules、カスタム DB スクリプト、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 は、どちらも破壊的変更を引き起こす可能性があることに注意してください。自動デプロイの合間にダッシュボードで直接行った手動変更は失われる可能性があります。そのため、どちらかを使用する場合は、すべて の変更をツールで参照するソース管理サブシステムからデプロイし、手動で変更を加えないようにする必要があります。
各環境では、環境固有の設定も必要になる場合があります。たとえば、アプリケーションの は Auth0 テナントごとに異なります。そのため、値をハードコードするのではなく、これらを動的に参照できる方法が必要になります。Auth0 では、環境固有の設定情報を扱う方法として、次の 2 つのアプローチのいずれかをサポートしています。
  • テナント固有の変数 を使用する
  • Auth0 Deploy CLI tool を使用している場合は、キーワード置換を使用する

テナント固有の変数

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

ベストプラクティス

テナント固有の値や、カスタムコードに含めて公開すべきでない機密シークレットは、変数に格納することを推奨します。カスタムコードを GitHub/Gitlab/Bitbucket/VSTS にデプロイしている場合、テナント固有の変数を使用することで、リポジトリ経由で機密値が露出するのを防げます。

プロジェクト計画ガイド

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