What is a Context?

Last updated on Mar 3, 2026

---

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

1. 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.

2. 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.

3. 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.

Why are some Liquibase changeSets with no context being deployed in one execution, but skipped in another when using Harness DB Ops?

This behavior occurs due to how Liquibase evaluates contexts at runtime in conjunction with the context configured in the Harness DB Schema Instance.

databaseChangeLog:
- changeSet:
    id: 1
    context: "@v1"
    ...

- changeSet:
    id: 2
    ...

- changeSet:
    id: 3
    ...

If a context (for example, v1) is defined at the DB Instance level, Harness passes that value to Liquibase during execution. In this scenario:

• Only changeSets explicitly matching that context (e.g., context: "@v1") will execute.
• changeSets without any context defined will be skipped.

However, if no context is defined at the DB Instance level:

• Liquibase applies no context filter.
• All changeSets execute, regardless of whether they define a context.

Therefore, the inconsistency is not a defect but a result of differing runtime configurations. When a context filter is applied, Liquibase strictly executes only matching changeSets. When no filter is applied, it executes all changeSets.