In have two instances of the same application running in production (Grails application running in a Tomcat, with the liquibase plugin). For reasons that are out of my control, I can’t deploy them at the same time, and one of them will not be deployed for some time.
They use the same database.
I recently made some changes to our database (adding fields to a table) in our development environment (only one application instance is running in dev). I created a changeset in the changelog.xml file, and applied it to the database. Everything works fine. I also modified my application code to use the database changes.
Eventually, I will deploy one of the application instances into production, after updating the production database. The other instance won’t be deployed (the old changelog.xml will be kept).
Could that cause problems? Since liquibase (in our application) checks for updates when the application starts, if I restart the old application, for example, will the update process fail, preventing the application to start?
I have done some tests, and looked in the liquibase source code, and it seems that the update/validation process only checks if all the changesets in changelog.xml are in the database. It doesn’t check if the database has more recent changesets than changelog.xml.
Is that correct? Could there be a problem eventually? Is there a “clean” way to handle it? Our second application instance is critical and we can’t afford to have it down if liquibase validation fails on startup.
That is correct, liquibase only looks at the changeSets in your current databasechangelog file, and looks to see if those changeSets have been applied or not. If there are other changesets in the databasechangelog table, liquibase does not care.
As long as you do not have duplicated id/author/filename identifiers for different changeSets and/or changes to a changeSet that would cause a checksum error, you should be fine.