![[Mastering Oracle SQLcl Liquibase - Part 3/3] - Synchronize your existing environments](https://cdn.hashnode.com/res/hashnode/image/stock/unsplash/p0FTPPhgZdQ/upload/69cc7f9e10433f6dfa54925576479d51.jpeg?w=1600&h=840&fit=crop&crop=entropy&auto=compress,format&format=webp)
3 likes
·
254 reads
3 comments
Hi Rafal, thanks for the detailed explanation of how to use Liquibase on an existing environment.
Let's say I have a dev environment with 105 tables of which 5 of them are used by developers to try out new features and rest 100 tables I would like to keep in sync in UAT. What would be the best approach?
Hi Richard! Thanks for asking. The answer is: it depends :) I would see some approaches for that:
- Every developer cleans his mess before you will run the generate-schema command versus DEV and then update to UAT ( so you don't have those tables then)
- Manually remove those changesets (with those 5 not needed tables) from files generated by generate-schema and then update to UAT
- You run generate-schema only at the beginning of your journey with SQLcl Liquibase. After that, every developer creates his changesets and commits them to git. Those 5 tables will not be added there, so they will not be deployed to UAT during the update.
- After running generate-schema on DEV, edit the changesets with those 5 tables and add a tag contexts="DEV_ONLY" ( or any other name ). When deploying to UAT, use liquibase update -changelog-file controller.xml contexts="!DEV_ONLY." Thanks to that, changes with contexts DEV_ONLY will not be deployed.
And a few more approaches, I suppose. Hope it helps. Rafal
Rafal Grzegorczyk Thanks again for the suggestions. I think point #4 would be a great idea to add tags and using it while updating the UAT environment.
Trying to get started on a DEV environment where there are 100s of temp tables created as part of nightly processing every day. :-)