Deployment Automation (B2C)

In addition to adopting best practices for change management and QA, successful customers will also integrate Login 3.0 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 Login 3.0 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. All deployment automation configurations must be handled by the UPBOND team upon request.

Best Practice

However you configure deployment automation, we 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 pro

Each environment may also need some environment-specific configuration—Application Client IDs and Client Secrets will be different between the Login 3.0 tenants, for example—so you’re going to want some way of being able to dynamically reference this rather than having hard-coded values. Login 3.0 provides support for handling environment-specific configuration information through one of the following two approaches:

• Use Tenant Specific Variables

• Use keyword replacement if using the Login 3.0 Deploy CLI tool

Tenant Specific Variables

Login 3.0 allows you to configure variables that are available from within custom extensibility; these can be thought of as environment variables for your Login 3.0 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. Tenant-specific variables must be configured by the UPBOND team upon request.

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. All tenant-specific variable configurations must be requested from the UPBOND team.