Separating Testa Data from Production Data

Community Answers
1

We need a way to unit-test the database layer and make sure the test data stored in the database is up-to-date with the latest database schema.

This article suggests to use the Liquibase execution context feature for that purpose, but unfortunately that feature, in its current state, is not usable for us, because there does not seem to be a way to make sure that the test data is ONLY loaded when the test context is provided explicitly. If you omit the context, EVERYTHING, including the data tagged with the test context, is loaded by default.

How do you guys tackle this problem?

Thanks for any input,
Steffen

2

Once you start using Liquibase contexts, you need to ensure that a context is provided for all environments at runtime, in order to prevent the scenario that you described from occurring.

Scenario: you have 3 environments (“dev”,“test”,“prod”). You have a changeset that is “test” only, so you code context “test” into that changeset. Even though you are only using context “test”, you will still need to provide the proper context at runtime for all environments (“dev”, “test”, and “prod”). This will prevent the “test” changeset from deploying to “dev” and “prod”.

Examples:

–dev deployment
liquibase --changeLogFile=changelog.xml --contexts=“dev” update

–test deployment
liquibase --changeLogFile=changelog.xml --contexts=“test” update

–prod deployment
liquibase --changeLogFile=changelog.xml --contexts=“prod” update

3

Thanks for your response. That’s bad, because that means we cannot use this feature (the existing changesets are run by our users in production). :frowning:

4

@soffermann
In my projects we sometimes do that way:

  • add preConditions to changesets and check the existence of some value e.g SELECT environment FROM parameters.
  • and check the value of this column
  • if it’s TEST then execute sth, if PROD then do sth else or do not execute
5

Thanks! Yes, that’s very similar to the solution we came up with, but we are using a custom precondition and check for the value of a Java system property. :slight_smile:

See this thread, too!