Best practices for deploying to Teradata schemas with varying schema names in the pipeline

Reference the schema name with a property

Reference the target schema with ${TARGET_SCHEMA} in your changeset. The changeset stays identical in every environment. Only the value of TARGET_SCHEMA changes.

Supply the value for each environment

The changeset never changes. You supply a different value for TARGET_SCHEMA in each stage of your pipeline. For a pipeline, the recommended approach is context-based properties: declare a value for each context at the top of your changelog, before any changesets.

Then select the environment at deploy time by passing its context. For example, --context-filter=DEV makes ${TARGET_SCHEMA} resolve to DEV_SCHEMA, so the change deploys to the DEV schema. Pass the context whichever way fits your pipeline, or override the value directly with -D (useful for formatted SQL changelogs or pipeline-generated names).

Be sure to:

• Replace your_database_url with your Teradata connection URL. For example, jdbc:teradata://your_hostname/DATABASE=your_database

• Replace your_username and your_password with your credentials

• Replace DEV (or DEV_SCHEMA) with the context or schema for the environment you are deploying to

Vary included paths by environment

You can use the same approach to control which files Liquibase includes. Reference a property in an includeAll path so each environment pulls in its own set of scripts. As with the schema name, you write ${TARGET_ENV} once and supply its value per environment.

When TARGET_ENV is set to PROD, Liquibase replaces the variable with PROD and includes all of the files from the scripts/PROD/ directory.