I’ve just entered a project where they have been using Liquibase for a while. They have had their first release. The first release is always easy since there is no previous database to consider.
Since knowledge of Liquibase has been limited in the project some not so good actions have been taken along the way.
For example, they have re-generated the changelog several times without thinking of that migrating their SystemTest, IntegrationTest and in the end Production environment with Liquibase would be impossible since changeSet’s in databasechangelog no longer match their changesets in xml.
The SystemTest environment is the first database that have to be migrated to the next version. In that database lots of data have been entered by test persons and we dont want to destroy that data.
The strategy I have been thinking of using is to find out the difference between the systemtest-db and a database generated by the latest changelog.xml. In that way I will have the delta. The base which is not the delta will be used as the baseline-schema xml. I then create records in systemtest-db’s databasechangelog table that matches the baseline-schema xml.
When the next release is finished I can run Liquibase update on my latest xml against the databasechangelog in systemtest db and will have that db up-to-date.
“Changelog Generation: The cause of and the solution to so many problems”
So the problem is that you have 3 versions of databases, and none of them match the changesets in the changelog, and they are all at different states? Your approach seems generally good. A couple tricks I have used in the past:
there is a changeLogSync command that will mark all changeSets in a changelog as ran
I’ve used preconditions on the changeSets to check to see if they have already ran or not (like a precondition on a ). The onFail=MARK_RAN attribute is what you would use so they are not re-evaluated all the time.
Originally posted by: Nathan
"Changelog Generation: The cause of and the solution to so many problems" :)
So true! :)
So the problem is that you have 3 versions of databases, and none of them match the changesets in the changelog, and they are all at different states?
Yep, I have glanced through the databasechangelog and compared it to changesets in the code base. They do not match unfortunately.
Your approach seems generally good. A couple tricks I have used in the past:
- there is a changeLogSync command that will mark all changeSets in a changelog as ran
- I've used preconditions on the changeSets to check to see if they have already ran or not (like a precondition on a ). The onFail=MARK_RAN attribute is what you would use so they are not re-evaluated all the time.
In this case since the databasechangelog seems no good, I am thinking of just replacing it with fresh data that matches the baseline-schema.xml
svaret agreed with you, Liquibase has ability to create changelog for generating an existing database.
But like its ability to split change log into many files most. Its goods for easier management of those files and database.
