Java.DBMigrationTools.What are contexts and how are they used?

Contexts are a Liquibase feature that lets you control which changesets run in which environment or situation.

One-sentence definition (interview-ready)

Contexts are tags on Liquibase changesets that determine whether a change runs based on the active environment (dev, test, prod, etc.).

What problem contexts solve

Without contexts:

every changeset runs everywhere
dev/test-only data or helpers accidentally reach prod

With contexts:

you scope migrations intentionally

Typical needs:

test data only in dev
debug helpers only locally
prod-only hardening steps

How contexts work (mechanics)

1️⃣ Define context on a changeset

<changeSet id="seed-test-users" author="stanley" context="dev,test">
    <insert tableName="users">
        <column name="email" value="test@example.com"/>
    </insert>
</changeSet>

This changeset runs only if the active context matches dev or test.

2️⃣ Activate contexts at runtime

In Spring Boot:

spring:
  liquibase:
    contexts: dev

Or via CLI:

liquibase update --contexts=prod

3️⃣ Matching rules (important)

Contexts are ORed by default
(dev,test → runs in dev or test)
You can use expressions:
- dev AND !prod
- test,staging

Liquibase evaluates this before executing a changeset.

Typical real-world use cases

✅ Good uses

Seed/demo data
Test fixtures
Debug helpers
Environment-specific permissions
Temporary safety checks

❌ Bad uses (red flags 🚨)

Core schema changes
Table/column creation
Business-critical data migrations

Schema evolution should be environment-independent.

Contexts vs labels (quick clarity)

Feature	Contexts	Labels
Purpose	Environment control	Logical grouping
Typical meaning	dev / test / prod	feature-x / hotfix
Who sets it	Runtime config	Migration author

(You can combine them, but most teams don’t need both.)

Interview pitfall to avoid ❌

“We use contexts to decide which schema changes go to prod.”

That signals fragile migrations.

Correct framing:

Contexts are for optional or environment-specific changes, not core schema evolution.

Interview-ready answer (2 sentences)

Contexts in Liquibase are environment tags on changesets that control whether they execute based on the active runtime context. They’re commonly used for dev/test data or environment-specific operations, while core schema migrations remain context-free and always run.

Senior rule of thumb

If a schema change must exist for the app to work, it should not be hidden behind a context.