導入の自動化（B2B）
変更管理とQAのベストプラクティスを採用するだけでなく、成功する顧客はAuth0の資産管理を自動化された導入プロセスの一部として統合します。SDLCサポートのアーキテクチャセクションで説明されているように、開発・テスト・運用環境用に個別のAuth0テナントを構成し、各環境でのテナントの構成がほぼ同じであるようにします。導入を自動化すれば、各環境のテナントが確実に同じ構成になるため、環境間での構成の不一致に起因するバグがほとんど生じなくなります。
ベストプラクティス
デプロイメントの自動化を構成しても、デプロイメント前にルール、カスタムDBスクリプト、フックをユニットテストし、デプロイメント後のテナントに対していくつかの統合テストも実行することをお勧めします。詳細は、「品質保証」のガイダンスをご覧ください。 :::
Auto0では、2つの方法で導入を自動化することができ、必要であれば両方を組み合わせることもできます。
Auth0 Deploy CLIツーリングでは、使いやすいスクリプトを利用して既存の継続的統合/継続的デリバリー（CI/CD）パイプラインと簡単に統合できます。
直接統合できない場合や、CI/CDパイプラインがない場合は、Auth0のSource Control Extensions（ソースコントロール拡張機能）を使用することで、簡単に設定できる基本的な自動化プロセスを提供し、非常にわずかなメンテナンスで済ませることができます。
Deploy CLIツールとソース制御拡張機能は、どちらも破壊的な変更を引き起こす恐れがあります。自動デプロイメントの合間にダッシュボードで手動で行った変更が失われる可能性があるためです。そのため、いずれかを使用する場合は、すべての変更を、ツールを介して参照元のソース制御サブシステムから導入するようにします。
それぞれの環境で異なる構成が必要なこと（たとえば、アプリケーションクライアントIDやクライアントシークレットがテナントごとに異なる、など）もあるため、ハードコード化した値ではなく、異なる値を動的に参照できる何らかの方法が必要になります。Auth0は、環境によって異なる構成情報を扱う方法として、以下の2つをサポートしています。
テナント固有の値
Auth0を使用すると、カスタム拡張性内から使用できる変数を構成できます。これらは、Auth0テナントの環境変数とみなすことができます。ハードコード化された参照は、開発・テスト・運用環境間で移動すると変わってしまうため、代わりに、テナントで構成され、カスタムの拡張コードによって参照される変数名を使用することができます。コードが変数を参照すれば、実行時にテナント固有の値が書き込まれるため、同じカスタムコードを異なるテナントで問題なく使用できます。
アクションの変数を使用するには、 Write Your First Action（最初のアクションを書く）を読み、エディターでシークレットを構成する方法を学びましょう。
ルールでの変数の使用については、値の設定方法
フックでの変数の使用については、エディターでシークレットの構成方法を参照してください
カスタムDBスクリプトでの変数の使用については、構成パラメーター
ベストプラクティス
テナント固有の値やカスタムコードで公開されるべきではない機密情報を含むために、変数を使用することが推奨されるベストプラクティスです。カスタムコードがGitHub/Gitlab/Bitbucket/VSTSにデプロイされている場合、テナント固有の変数を使用することでリポジトリを通じた機密値の公開を避けられます。
プロジェクト計画ガイド
当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。
B2B IAM Project Planning Guide複数Organizationアーキテクチャ（マルチテナント機能）
B2Bプラットフォームの多くが顧客のOrganizationを何らかの形で分離・ブランディングし、これがIDおよびアクセス管理（IAM）システムをさらに複雑にしています。この問題でお困りであれば、当社がそのような環境に合ったガイダンスとベストプラクティスをご紹介していますので、時間を割いてお読みになることをお勧めします。