> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/database-devops/3.0/use-db-devops/reference/glossary/context.md).

# What is a Context?

\
{\`\
{\
"@context": "<https://schema.org",\\>
"@type": "FAQPage",\
"mainEntity": \[\
{\
"@type": "Question",\
"name": "What is a context in Liquibase?",\
"acceptedAnswer": {\
"@type": "Answer",\
"text": "A context in Liquibase 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."\
}\
},\
{\
"@type": "Question",\
"name": "Can I assign more than one context to a changeset?",\
"acceptedAnswer": {\
"@type": "Answer",\
"text": "Yes. You can assign multiple contexts to a changeset by separating them with commas. For example: context: 'dev,test'. The changeset will run if either context matches."\
}\
},\
{\
"@type": "Question",\
"name": "What does the set-contexts command do in Liquibase?",\
"acceptedAnswer": {\
"@type": "Answer",\
"text": "The set-contexts command allows you to bulk edit and apply context values to changesets from the command line without modifying the changelog files directly. It works with YAML, XML, JSON, and SQL changelogs."\
}\
},\
{\
"@type": "Question",\
"name": "Do I need Liquibase Pro to use multiple contexts?",\
"acceptedAnswer": {\
"@type": "Answer",\
"text": "No. You can assign multiple contexts in open-source Liquibase as well. However, advanced commands like set-contexts are part of Liquibase Pro."\
}\
},\
{\
"@type": "Question",\
"name": "How do contexts work in Harness Database DevOps?",\
"acceptedAnswer": {\
"@type": "Answer",\
"text": "In Harness Database DevOps, the context filter in the DB Instance step determines which changesets will run. If no filter is provided, all changesets, including those with contexts, are executed."\
}\
}\
]\
}\
\`}<br>

### What you will learn <a href="#what-you-will-learn" id="what-you-will-learn"></a>

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 <a href="#why-contexts-are-useful" id="why-contexts-are-useful"></a>

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 <a href="#how-to-use-contexts-in-changelogs" id="how-to-use-contexts-in-changelogs"></a>

You can define contexts in your changelog files in formats like YAML, JSON, SQL, or XML. The following is an example using YAML:

```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 <a href="#how-to-write-a-changeset-with-multiple-contexts" id="how-to-write-a-changeset-with-multiple-contexts"></a>

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:

```bash
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](/database-devops/use-db-devops/reference/glossary/changeset.md) run during a migration operation.

#### How contexts work in Harness Database DevOps <a href="#how-contexts-work-in-harness-database-devops" id="how-contexts-work-in-harness-database-devops"></a>

The following table describes how Harness Database DevOps evaluates changesets based on your context configuration.

| Behavior                        | What It Means                                                                                                |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Default behavior**            | If you do not 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 <a href="#conclusion" id="conclusion"></a>

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

### Next steps <a href="#next-steps" id="next-steps"></a>

* Learn about [Changelogs](/database-devops/use-db-devops/reference/glossary/changelog.md) to understand how changesets are grouped and executed in sequence.
* Explore [Changesets](/database-devops/use-db-devops/reference/glossary/changeset.md) to understand how individual database changes are defined and managed.

### FAQ <a href="#faq" id="faq"></a>

#### 1. What is a context in Harness Database DevOps? <a href="#id-1-what-is-a-context-in-harness-database-devops" id="id-1-what-is-a-context-in-harness-database-devops"></a>

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? <a href="#id-2-what-are-some-best-practices-for-using-contexts" id="id-2-what-are-some-best-practices-for-using-contexts"></a>

* 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? <a href="#id-3-can-i-assign-more-than-one-context-to-a-single-changeset" id="id-3-can-i-assign-more-than-one-context-to-a-single-changeset"></a>

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

```yaml
context: test,dev
```

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

#### 4. Why are some Liquibase changesets with no context being deployed in one execution, but skipped in another when using Harness DB Ops? <a href="#id-4-why-are-some-liquibase-changesets-with-no-context-being-deployed-in-one-execution-but-skipped-i" id="id-4-why-are-some-liquibase-changesets-with-no-context-being-deployed-in-one-execution-but-skipped-i"></a>

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

```yaml
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.