Even if you want nothing to do with Rails you should take a look at Rails Migrations because it is the best solution I have found to such a common development problem. The problem being how to make updates to your various databases in a sane manner.
Start with the quick screencast. Then check out this nice cheat sheet.
I know a couple of people are trying to figure out how to do something like this in .NET, if I had more time I would give it a try as well.
-James
{ 3 comments }
We keep our SQL Server database always buildable from scripts in source control. Every build (and we’re using CruiseControl.NET, so that means on every check-in) recreates an (empty) instance of the database from source control.
To publish schema changes to QA and then to Production, we use a commercial product called “SQL Compare” by Red Gate. It works fantastically well, in the sense that we’ve been running this way for 10 months with no problems.
Note that this is pretty much a forward-only system. We don’t hand code delta scripts, or even keep the generated upgrade scripts under source control. So rolling back more than a single version would be problematic if we ever needed to do that (but we haven’t.)
The Castle Project has a Migrations section for Monorail I think, but it can be used standalone.
It’s not as elegant as Rails migrations, but then again not much is
SubSonic has migrations coming in its next stable version.
I believe the bits are already in svn if you wanted to take a peek, but I may be wrong.
Comments on this entry are closed.