How To: Deploy Changes to a Specific Environment

There are certain changes that only need to be deployed to one or few environments instead of deploying to every environment. For example, deploy changes to QA only (or STAGE only or PROD only). 

Using metadata.properties and the use of "context" help us achieve this goal. A "context" refers to a specific database (or databases) in the pipeline. When a Datical pipeline is configured, each connection to database is given a context. This context can be used to perform deployments. 

Where do you specify context for a database environment in Datical project?

• In Datical DB GUI, click on "Edit Connection" link for each database in the project:
• 
• Specify context here. If no context is provided, click on the "Configure" button on the right to type in the context
•  → 
• Click "OK".
• Repeat for all database environments in the project, including database environments in other pipelines that exist in the project.
  • Your context can match your database name as shown in the table below:

    • Database name	Context
      REF1	REF1
      DEV	DEV
      QA	QA
      STAGE	STAGE
      PROD	PROD

• Finally, make sure to push the project into your SCM (e.g., Bitbucket).

Step-by-step guide

1. Setup directory structure such that there are context-specific subdirectories in EACH of the sql_code directories (data_dml, ddl, ddl_direct, function, package, packagebody, procedure, sql, sql_direct, trigger, and view)
   • For example, in data_dml directory, there would be three DEV directories - one for each DEV environment - DEV1, DEV2 and DEV3
   • 
   • In each of the subdirectories, there would be a "metadata.properties" file which would contain "contexts" flag:
     • In PROD-only subdirectory, the "metadata.properties" file would contain "contexts=PROD"
     • In STAGE-only subdirectory, the "metadata.properties" file would contain "contexts=STAGE"
     • In QA-only subdirectory, the "metadata.properties" file would contain "contexts=QA"
     • In DEV-only subdirectory, the "metadata.properties" file would contain "contexts=DEV"
     • In REF1-only subdirectory, the "metadata.properties" file would contain "contexts=REF1"
     • In until-DEV subdirectory, the "metadata.properties" file would contain "contexts=REF1,DEV"
     • In until-QA subdirectory, the "metadata.properties" file would contain "contexts=REF1,DEV,QA"
     • In until-STAGE subdirectory, the "metadata.properties" file would contain "contexts=REF1,DEV,QA,STAGE"
2. Database developer commits scripts into the appropriate subdirectory. 
   
   • For example, if a DML script only needs to be deployed into QA environment, then the developer would commit that scripts into the following subdirectory:
     • sql_code → data_dml → QA-only
     • 
3. When the packager picks up scripts from this subdirectory (e.g., sql_code\data_dml\QA-only), it will automatically apply the "QA" context to resulting changsets.
   
   • Let's say "customer_billing_SEPT.sql" script is committed into sql_code\data_dml\QA-only subdirectory
   • When packager runs, it will pick up this script and realize that there is a metadata.properties file located in the same subdirectory and it contains contexts=QA. Therefore, packager will apply this context to all changesets generated from this sql script
   • 
   • Now, when you deploy your changes to QA environment, these changesets will be DEPLOYED.
   • When you deploy your changes to other environments (DEV, STAGE or PROD), these changesets will be SKIPPED because the context for these changesets do not match with the database context as specified in the Datical project.

Related articles

• Page:
  How To: Remove abandonded changes from Liquibase Enterprise and lower environments
• Page:
  How To: Make Liquibase Enterprise Aware of Manual Hotfixes
• Page:
  How To: Abandon a Single Changeset from a Script
• Page:
  How To: Deploy Changes to a Specific Environment
• Page:
  How To: Leverage the "metadata.properties" file