How is liquibase rollback supposed to work?

Question

I am just getting started with liquibase and it seems quite useful. My biggest issue is with rollback.

I'm baking my liquibase changelog into the jar that has my data layer in it and on app startup, I'm migrating automatically using the changelog in the jar in the app. If I'm only moving forward, this works fine.

But if I have two branches each working on that data layer jar and I want to switch back and forth between them using the same DB, it doesn't work because the changelog in one branch has different changesets than the other. In and of itself, that isn't a problem, but when I swap branches and start my app, it doesn't know how to rollback the changesets from the other branch because they are not in the changelog yet.

Is the answer here to just be careful? Always use separate DBs?

Why not put rollback into the DATABASECHANGELOG table in the DB so unknown changesets can be rolled back without the changelog file?

Answer 1

You are right that rollback simply looks at the applied changes in the DATABASECHANGELOG table and rolls changeSets back based on what is in the changelog. It could store the rollback info in the DATABAESCHANGELOG table, but it doesn't for a variety of reasons including simplicity, space, and security. There are also times it can be nice to roll back changes based on updated changeSet rollback info rather than what was set when the changeSet was first executed.

In your case, rollback is more complex because you looking to switch branches frequently. What I've generally found is that feature branches tend to make relatively independent changes and so even if you change between branches, you can leave the database changes in because they created new tables or columns which the other code simply ignores. There are definitely times this is not true, but within the development environment you find the problems right away and can address them as needed. When you do find times you need to roll back changes from another branch you can either remember to roll back changes before switching branches. Some groups don't bother with rollback at all and just rebuild their development database when needed (liquibase "contexts" are very helpful for managing test/dev data).

As you move from development to QA and production you normally don't have to deal with the same level of branch changes and so there is normally no difference between the changeSets you are looking to roll back and what is in the changelog.