Sorry, I am still missing something. That’s fine if YOU do not have direct access but Liquibase has access to production right?
So, when liquibase tries to run a changeset it will look in the changelog table to see if it already ran past changesets before it runs. So, I would just put a changeset for table ABC, and then if you find it is in production (how does it get there but you don’t see it in lower environments?) I would just mark that changeset as ran thru a changelog sync.
If you are saying tables are created directly in prod, we have a best practice for that as well:
- create table in prod (possibly b/c of a hotfix or whatever)
- create a changeset in the changelog afterwards
- perform a changelog sync on prod to indicate to liquibase it has ran (essentially it updates the dbchangelog table)
- run liquibase update on the lower environments to accommodate for the hotfix.
You will need to get some communication on schema changes happening directly in prod. Liquibase was meant to be the only updater to that schema. Sometimes that is not always feasible but you do have to go back and tell liquibase.
I would discourage use of logic in your prod deployments. That’s an anti-pattern and you can’t rehearse for a release and know 100% for sure what will happen.