Skip to main content
In addition to adopting best practices for change management andĀ QA, successful customers will also integrate Auth0 collateral management as part of some automated deployment process. As discussed in the Architecture section underĀ SDLC support, you will want to ensure you configure separate Auth0 tenants for development, testing, and production environments, and you will want that configuration to be almost identical for the tenant in each environment. Using deployment automation helps ensure this, so that each environment tenant is configured the same, and you will be less likely to see bugs show up as a result of mismatched configurations between environments.

ā€‹
Best Practice

However you configure deployment automation, weā€™d recommend you unit test your rules, custom DB scripts, and hooks prior to deployment, and run some integration tests against your tenant post-deployment too. For more details regarding this, see the Quality Assurance guidance provided.
Auth0 provides support for a couple of different options when it comes to the deployment automation approaches you can use, and each can be used in conjunction with the other if desired:
  • TheĀ Auth0 Deploy CLI toolingĀ provides you with an easy-to-use script that can help you integrate with your existing Continuous Integration/Continuous Deployment (CI/CD) pipeline.
  • If you canā€™t integrate directly with, or for some reason you donā€™t have a CI/CD pipeline, then the Auth0Ā Source Control ExtensionsĀ can provide an easy-to-set-up basic automation process with very low maintenance.
Note that both the Deploy CLI Tool and source control extensions can cause destructive changes; manual changes made directly in the dashboard between automated deployments could be lost! For this reason, if either is used, thenĀ allĀ changes should be deployed from the source control subsystem referenced via the tooling and not made manually.
Each environment may also need some environment-specific configurationā€”Application ā€™s and will be different between the Auth0 tenants, for exampleā€”so youā€™re going to want some way of being able to dynamically reference this rather than having hard-coded values. Auth0 provides support for handling environment-specific configuration information through one of the following two approaches:

ā€‹
Tenant specific variables

Auth0 allows you to configure variables that are available from within customĀ extensibility; these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants as the code can reference variables which will be populated with tenant-specific values at execution time:

ā€‹
Best Practice

Itā€™s a recommended best practice to use variables to contain tenant-specific values as well as any sensitive secrets that should not be exposed in your custom code. If your custom code is deployed in GitHub/Gitlab/Bitbucket/VSTS, then using a tenant-specific variable avoids exposure of sensitive values via your repository.

ā€‹
Project Planning Guide

We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies. B2C IAM Project Planning Guide