I currently evaluate how my organisation could make use of liquibase as DB versioning system.
However, I do have difficulties on how the liquibase philosophy fits into our current workflow:
Currently we have the CREATE and initial fill sql scripts of our application under version control. As soon as there is a change (e.g. new column) the programmer adjusts the CREATE script and checks the changes in. Since application code and SQL scripts are in the same repository the DB objects should be always in sync with the application version.
Additionally, for each release we maintain a list of ALTER... statements which are used when the customer upgrades our software (which is much more often the case then installing from the scratch).
So we have two worlds - the current version of the schema objects as CREATE statements in the repository plus a list of necessary actions to get from version 1 to 2 (ALTER statements).
What I like is that the definition of the schema objects always matches the version of the software since the are in the same version control repository.
What I don't like (and hence looking for an alternative) is the double work we have to do. Furthermore, since the software is more updated than newly installed, the CREATE statements are more of a documentation but are rarely applied to the database.
What I understood is, that liquibase starts with a baseline and is then operating on small change sets. So I would once check in the base line and then add my small change sets.
Over the time I might have an old baseline with lots of change sets. I assume I then have to manually generate a new baseline out of old baseline + changesets and start from there again. This sounds rather confusing to me. I'm also not sure if my co-workers would see the benefits compared to our current workflow.
What would you recommend?