変更管理と QA のベストプラクティスを採用することに加え、導入に成功しているお客様は、自動化されたデプロイプロセスの一部として Auth0 の構成管理も統合しています。アーキテクチャセクションの SDLC support で説明しているように、開発、テスト、本番の各環境ごとに個別の Auth0 テナントを構成し、それぞれの環境のテナント構成をほぼ同一に保つことが重要です。デプロイ自動化を利用すると、各環境のテナントを同じ構成に保ちやすくなり、環境間の構成の不一致に起因するバグの発生を抑えられます。
ベストプラクティス
どのような方法でデプロイ自動化を構成する場合でも、デプロイ前に Rules、カスタム DB スクリプト、Hooks の単体テストを実施し、さらにデプロイ後にはテナントに対して統合テストも実行することをお勧めします。詳しくは、Quality Assurance のガイダンスを参照してください。
- CI/CD パイプラインに直接統合できない場合、または何らかの理由で CI/CD パイプラインがない場合は、Auth0 の Source Control Extensions を使用することで、セットアップが簡単で保守の手間も非常に少ない基本的な自動化プロセスを利用できます。
- 既存の CI/CD ツール (例: Jenkins、GitHub Actions、GitLab CI など) と連携して、デプロイプロセス全体を自動化することも可能です。
- カスタムスクリプトや社内ツールを用いて、特定のワークフローや要件に合わせた自動化を構築することもできます。
Deploy CLI Tool と Source Control Extensions はどちらも破壊的変更を引き起こす可能性がある点に注意してください。自動デプロイの合間にダッシュボードで直接行った手動変更は失われる可能性があります。そのため、いずれかを使用する場合は、すべて の変更をツールで参照するソース管理サブシステムからデプロイし、手動では変更しないようにしてください。
- Auth0 Deploy CLI ツールを使用している場合は、キーワード置換を使用する
Auth0 では、カスタムの拡張機能内から利用できる変数を設定できます。これらは、Auth0 テナントの環境変数のようなものと考えることができます。開発、テスト、本番の各環境間でコードを移すたびに変わる参照をハードコードする代わりに、テナントで設定した変数名を使用し、その変数をカスタム拡張コードから参照できます。これにより、実行時にテナント固有の値が設定される変数をコードから参照できるため、同じカスタムコードを変更せずに異なるテナントでも動作させやすくなります。
ベストプラクティス
テナント固有の値だけでなく、カスタムコード内で公開すべきでない機密情報を保持するためにも、変数を使用することを推奨します。カスタムコードを GitHub/GitLab/Bitbucket/VSTS にデプロイしている場合、テナント固有の変数を使用することで、リポジトリを通じた機密値の漏えいを防げます。 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム