I’ve gone through a number of the documentation (including the maven liquibase plugin), and I’m kinda running into a block regarding my use-case of how I would like to use liquibase (which, hear me out, may be inappropriate or appropriate for this scenario).
The point-of-view is from an application developer trying to manage change.
DEV database (mysql, ms sql, etc)
STAGING database(mysql, ms sql, etc)
LIVE database(mysql, ms sql, etc)
This is where I’m a little unsure – we have (well, trying) to have all database changes done only in the DEV environment. However, here is the catch – those changes could be done by external tools such as Modelling tools, DB-specific administration tools, or scripts. All those changes are done, basically, outside of our control for this conversation (I’m sure a lot of app developers have similar environments).
We would like to manage/control the end-result of all the aggregated changes and create the delta scripts that will actually be applied to STAGING, and future LIVE. Also, I very much like the SQLDOC change document and although it will not get the user/comments based on the external changes, at least keeping track of those changes in that format is very useful.
Also, as an application developer, we use Maven and would like to leverage if possible, but if this scenario is best handled outside of Maven that would be fine.
How can we use Liquibase for this scenario?
*Establish a baseline (for each major version/release).
*Throughout the iterations keep track of changes (even though they were done externally to liquibase). Generate sqldoc like change documentation if possible/reasonable.
*Throughout the iterations in preparation for release (which may still be several iterations), create the SQL output of changes from the baseline to current desired state. Possibly SQL output in between releases, but do not want to confuse things and just pick which approach is best managed/best practice. Liquibase would not make changes to STAGING, instead create the SQL scripts that would be applied to STAGING.
*Once released re-establish baseline and repeat from top.
–hopefully not have to manually create the dataset/changesets and instead reverse engineer from existing database implementation.
I definitely hope to grow to actually leverage the full functionality of liquibase, but need to get it started and used regularly first to recognize the usefulness/value (i.e. “Manager, if you want to see the author/comments in the sqldoc change logs, dont use the external toosl and instead to do it this way…”).
Thank you for any feedback,