Database migrations

I was originally looking for a way to organize our db-scripts so we could do a full drop and recreate before running tests, or deploying a new version. One of the main disadvantages to this is that test data will get lost. By separating the scripts you can still maintain upgrade scripts for when you are going live with a new version.

But since we have many interested parties, asking them to drop all their carefully crafted test data is not an option. That’s when I stumbled across DBDeploy. It is beeing developed by a bunch of Thoughtworks guys, and it supports upgrade/downgrade in small increments. It seems alright, though it’s doesn’t seem to be under active development. Last svn activity was in october last year, but I guess some simple things actually get done. 😉 I’ll report back when we get some experience with it.

3 replies on “Database migrations”

Ping the list if you run into issues with DBDeploy – it is very actively used (even if there are no recent commits), and the community would want to know if you run into any issues.

Excellent, I’ll be sure to do that. I was starting to think I needed to add the ability to set the name of the version table through a parameter, but you guys had thought of deltasets that did the trick for separating it all. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *