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 subsystem からデプロイし、手動で変更を加えないようにする必要があります。
各環境では、環境固有の構成も必要になる場合があります。たとえば、Application の や は Auth0 テナントごとに異なります。そのため、値をハードコードするのではなく、動的に参照できる仕組みが必要です。Auth0 では、環境固有の構成情報を扱う方法として、次の 2 つのアプローチをサポートしています。

​
テナント固有の変数

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

​
ベストプラクティス

テナント固有の値だけでなく、カスタムコード内に公開すべきでない機密情報を保持するためにも、変数を使用することをおすすめします。カスタムコードを GitHub/Gitlab/Bitbucket/VSTS にデプロイしている場合は、テナント固有の変数を使用することで、リポジトリ経由で機密値が漏えいするのを防げます。

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

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

​
複数組織アーキテクチャ (マルチテナンシー)

多くの B2B プラットフォームでは、顧客ごとに組織の分離やブランディングを何らかの形で実装しており、その結果、Identity and Access Management (IAM) システムが複雑になることがあります。これに該当する場合は、この種の環境に関するガイダンスやベストプラクティスをぜひご一読ください。 複数組織アーキテクチャ