Comments on: Rails Migrations http://averyblog.com/rubyrails/rails-migrations/ This is not the greatest tagline in the world... this is just a tribute. Mon, 11 Jan 2010 16:36:16 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: kevin http://averyblog.com/rubyrails/rails-migrations/comment-page-1/#comment-2173 kevin Mon, 01 Oct 2007 17:50:54 +0000 http://averyblog.infozerk.net/?p=653#comment-2173 <p>SubSonic has migrations coming in its next stable version.<br /><br />I believe the bits are already in svn if you wanted to take a peek, but I may be wrong.</p> 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.

]]> By: Ben Scheirman http://averyblog.com/rubyrails/rails-migrations/comment-page-1/#comment-2175 Ben Scheirman Mon, 01 Oct 2007 17:27:09 +0000 http://averyblog.infozerk.net/?p=653#comment-2175 <p>The Castle Project has a Migrations section for Monorail I think, but it can be used standalone.<br /><br />It's not as elegant as Rails migrations, but then again not much is :)</p> 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 :)

]]> By: Adam Vandenberg http://averyblog.com/rubyrails/rails-migrations/comment-page-1/#comment-2174 Adam Vandenberg Mon, 01 Oct 2007 16:12:34 +0000 http://averyblog.infozerk.net/?p=653#comment-2174 <p>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.<br /><br />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.<br /><br />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.)</p> 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.)

]]>