What is a Context?

A context in is like a filter or tag that helps decide which changesets should be applied when updating a database. It acts as a condition to control when and where specific changesets run. Contexts are especially useful when working with different environments like development, testing, and production, where you may not want every change to apply everywhere.

You can add a context directly to a changeset in your changelog, and then use a special Context option in "DB Instance" step to decide which changesets should run based on their assigned contexts.

Why Contexts Are Useful?

Contexts give you flexibility and control. For example :

• You might want to apply some changes only in the test environment and not in production.
• You can separate changesets meant for a particular feature, version, or phase of development.
• You can avoid running unnecessary or risky changes by applying filters during deployment.

In short, contexts help you run only what is needed, where it is needed. It makes managing database changes easier and safer, especially in complex projects with multiple environments and teams.

How to Use Contexts in Changelogs?

You can define contexts in your changelog files in formats like YAML, JSON, SQL, or XML. Here's an example using YAML:

databaseChangeLog:
  - changeSet:
      id: 2
      author: john-doe
      context: test
      changes:
        - insert:
            tableName: news
            columns:
              - column:
                  name: id
                  value: 1
              - column:
                  name: title
                  value: "Harness Database DevOps 1.27.x Released"

In this example, the changeset will only run if the context is set to "test", which you can specify in your deployment configuration.

How to write a changeset with multiple contexts?

You can assign multiple contexts to a changeset by separating them with commas. Harness DBOps supports basic logic operations for combining multiple contexts:

• AND: Both conditions must be true
• OR: Either condition can be true
• !: Means "not" or to exclude a context
• Parentheses (): You can group conditions
• Commas ,: They work like "OR"

For Examples:

context: "dev, qa"           # Runs if context is dev OR qa
context:"!prod and test"    # Runs if NOT prod AND is test
context:"v1.0 or !qa"       # Runs if v1.0 OR NOT qa

This logical control helps you fine-tune exactly which changesets run during a migration operation.

How Contexts Work in Harness Database DevOps?

Behavior	What It Means
Default behavior	If you don’t use a special context in DB Instance, all changesets—including those with contexts—will run.
With context filter	Only the changesets matching the filter will run. Others will be skipped.
Empty or strict context (@)	A changeset with @context runs only if that exact context is provided during the update.
Multiple contexts	You can assign multiple contexts to a changeset, and it will run if any of those contexts match.

Conclusion

Using contexts in Liquibase allows teams to manage database changesets with precision across environments like dev, QA, and production. In Harness Database DevOps, contexts act as environment-aware filters, improving deployment control, reducing risk, and enhancing change governance. Whether you're managing a handful of changesets or hundreds, features like the set-contexts CLI command bring scalability and ease. By applying these practices, you ensure reliable, environment-specific rollouts without unnecessary overhead.

FAQ

What is a context in Harness Database DevOps?

A context in Harness Database DevOps is a tag used to conditionally control which changesets are executed during a database update. It helps manage environment-specific changes, such as dev, test, or production.

What are some best practices for using contexts?

• Use for test data: Tag test data with context: test to exclude it from production deployments.
• Avoid using context for DB-specific logic: Instead, use the dbms attribute for targeting specific database types.
• Use include context inheritance: Add context in <include> or <includeAll> tags to propagate across included changelogs.

Can I assign more than one context to a single changeset?

Yes, you can assign multiple contexts to a changeset by separating them with commas. For example:

context: test,dev

This means the changeset will run in both test and development environments.