0
votes

I have a huge concern about the Liquibase behavior of ignoring changeset Context if no context is supplied as a run-time parameter.

I'm setting up my first Liquibase project, using "dev, test, prod" as contexts in changesets. I'm passing in the context from a Spring Boot application.properties, which will have different versions for dev, test, etc. So the PROD version will have spring.liquibase.contexts=prod. So far, so good.

But what will happen if somehow, years from now, that line gets accidentally deleted, or commented out? Or what if someone happens to run Liquibase against PROD and doesn't supply "prod" as context?

It seems to me that ALL prior changesets NOT marked with "prod" will then run. This would include any marked just "test", that insert test data, or--God forbid--drop tables... Worse, they'll be running out of order.

I understand Liquibase DOES recommend including "test"-only changesets along with everything else, and using the "test" context (only) to distinguish them.

So. Am I right that this is a potential disaster waiting to happen? Is there a way to prevent this?

Thank you, StackOverflows!!

1

1 Answers

0
votes

Yes, you are right that a potential disaster can happen. It could happen many other ways in your described process as well. This design is on purpose b/c most don't use contexts and so the majority want all changesets to run when you do an liquibase update.

A safety net I have seen at various places: Create a check for context around the liquibase command in your cicd automation instrumentation layer. For example those that use Jenkins, make sure there is a mandatory parameter for context before the build can even run.