Migration advice with generateChangeLog for deploying to production?

General Discussion
1

Situation:

We have a large monolithic Java service that has almost 10 years of changesets made by different dev agencies and contractors using different styles of changesets (XML, raw SQL, YML).

To make matters worse, there was no original baseline made by the contractors. So if you want to run locally, you have to take a mysqldump of the DB and then restore it to your local mysql instance,

We want to baseline the DB, however we are not sure how that will play out when it gets deployed to existing testing, staging and production environments.

I have tried googling what this process should be like, however I am not sure. So I have tried to come up with my own solution, please advise

  1. Get fresh MySQL dump from production / test
  2. Redact any sensitive information
  3. Restore DB locally on a fresh instance
  4. Run liquibase locally to generate the new changelog
  5. Copy the liquibase CHANGELOG table values
  6. Freeze any DB changesets for a week
  7. Delete old changesets from codebase
  8. Commit new changeset
  9. Login to test DB, copy new CHANGELOG table values into test schema
  10. Deploy new version of app with new changelog
  11. Test

x. Repeat for staging
x. Repeat for production

Will this solution work?

I am worried that it will try to apply the changelog to an existing schema on test, staging, production?

Any pointers welcomed!

2

I’m trying to understand your use case… what is the end goal here? Are you trying to flesh out a DATABASECHANGELOG table so that you can run Liquibase without any of the change sets actually running against the db?

If I’m reading it correctly, you want to duplicate tracking tables from your local machine db instance to the production instance so that Liquibase will think it has already applied the changesets… Is that accurate?

:slight_smile:

Welcome, btw!!

3

Hi erin,

Thanks for responding

Yea, we already have Liquibase changelogs in all environments. So I am anticipating a clash if those tables are not truncated and manually replaced with a new changelog generated in a local environment.

Is there another way to do this?

I don’t mind it being a manual process and we have bi-daily backups, so we can recover easily if anything goes wrong

4

Bump,

I have tested this process on a local environment and it seems to work.

Any inputs / thoughts?