What is Contexts and Labels?
Definition
Contexts are typically used to group ChangeSets by purpose or environment, such as tagging a set of ChangeSets as test-data-only, while Labels offer a more flexible, freeform way to tag and filter ChangeSets, useful for grouping changes by feature, team, or release. A deployment specifies which contexts or labels to include or exclude when it runs, and only matching ChangeSets execute. This lets one ChangeLog handle differences between environments, since dev needs sample data and production doesn't, without duplicating the file or maintaining parallel versions that inevitably drift apart from each other over time. The underlying change definitions stay identical; only which subset runs varies by deployment.
Why Contexts and Labels matter
Without a way to vary execution by environment, teams either maintain separate ChangeLogs per environment, which drift out of sync over time, or apply every ChangeSet everywhere, which means test data ends up in production or a development-only convenience script tries to run against a live system. Neither option is good. Contexts and Labels give a ChangeLog a built-in way to differ safely by environment without either drawback, and without requiring anyone to remember which script belongs to which environment.
How Contexts and Labels work
Each ChangeSet can be tagged with one or more Contexts or Labels, and a deployment command specifies which ones to include or exclude for that run. A ChangeSet with no tags typically always runs; a ChangeSet tagged as test data only runs when a deployment explicitly includes that context. This filtering happens at deployment time, based on the same underlying ChangeLog, so the file itself never needs to change between environments, only the command used to deploy it. Labels tend to be used more flexibly than Contexts, useful for grouping ChangeSets by feature or release rather than strictly by environment.
How Liquibase helps
Liquibase evaluates Contexts and Labels as part of every deployment, so a single ChangeLog file can serve development, staging, and production consistently, with environment-specific behavior handled by tags rather than by maintaining separate files. This ties directly into Multi-Environment Deployment: Contexts and Labels are the specific mechanism that makes running one ChangeLog safely across many environments possible in practice, rather than just a theoretical goal. Teams adopting this pattern typically settle on a small, consistent set of Contexts across all their ChangeLogs, since an unmanaged proliferation of ad hoc tags can become almost as confusing as the separate-file approach it was meant to replace. Renaming a Context after ChangeSets are already tagged with it is riskier than it looks, since anything still referencing the old name silently stops matching, so it's worth treating tag names as stable once they're in wide use.
