Loving Liquibase, use it every single day. Just a quick question about my way of versioning, whether or not it’s good or not, if there’s any potential downfalls that I’m just not seeing yet. I’m using the master-file system that is recommended on the Liquibase best practices page.
When I was setting up and designing our database, I was doing one changeLog per action (createTable, createProcedure, etc. would all get their own commented changeLog). This was useful for development, since so many changes happened so often. But now that I’m done with the initial setting up of the database and am ready to roll out, I went back and condensed all the individual changelogs down to only one per schema, with id=“schemaname-1.0.0” since this is the finished version “1”, it’s no longer in development. This way, when I run “update,” I have one “change” that is commented as “Setup EmployeeManagement schema,” and instead of 60 separate changeLog lines that happen at like 3-5ms, I get one big one that happens in around 400ms or so.
And then going forward as things need to be changed after deployment as either bug fixes or upgrades, I would increment the version numbers as follows:
#.0.0, this far left number would indicate a massive change such as the introduction and changing of multiple tables, multiple stored procedures, etc. all at once.
0.#.0 would indicate an addition of maybe one or two tables, neither a “ton” of stuff, nor just “one” change.
and 0.0.# would be for small single actions, like if I have two spelling mistakes in version 1.0.0, I would fix one in 1.0.1, and then fix the other in 1.0.2.
So far this is solid, I like it, it’s clean, and it makes sense. I just want to make sure there’s not some disadvantage I’m not seeing yet that has to do with changeLog’s being too long or too many things happening in one changeLog.
