3 ms·

We're in the midst of adopting Liquibase to support our schema on 3 different db's (Oracle, SQL Server, MySQL). Interested in hearing about any experiences or

• fusiongyro 11y ago
  I have been using it for the last five or so years and absolutely love it. I would recommend that you: - Make sure every code feature gets its own Liquibase migration file - Use the XML format—stronger IDE integration, and it's been around longer - If possible, use their migrations instead of raw SQL, since you will get the rollback functionality "for free." - Integrate it with the "deploy" phase of your Maven build, if applicable - Use the "reverse engineer" feature when you get close to deploying it the first time, to ensure that you have a from-scratch workflow that works and produces identical schemas You will get merge conflicts on the file that lists the migrations to apply, but they are obvious and trivial to fix. Pitfalls. The only one I've noticed is that it can be confused about Postgres types, but I have been able to the "rewrite" functionality to "fix them in post." I tried the YAML format and found that I missed the completion in the IDE that the XML format has, thanks to the schema. Otherwise, it works fine, but I like the validity angle. You can set up some migrations to be run every time. I usually set up the GRANTs that way, so I know the permissions are good right before a code deploy. Also, on those migrations, use an empty <rollback> clause so it doesn't prevent you from rolling back (you can do that on any migration to make Liquibase ignore it during a rollback operation, so all my data-manipulation migrations get one too).