Rails Migrations and Multiple Developers
Published 2 years, 8 months agoI’ve been reading a lot lately about the migrations feature of Ruby on Rails. Generally this looks like really cool functionality. However, one thing has been eating at me ever since I had my first glimpse at it:
How does it work in a multi-developer environment?
Now I know this has to have been considered in it’s design, and I’ve seen references to people using it, but I haven’t seen anyone mention how it’s handled.
Here’s the scenario I’m concerned about. The development team comes in one morning and everyone updates from source control. Everyone’s database schema is sitting at version 10.
Developer A sits down and starts working on feature A.1 which requires a new column on the users table. So he generates a migration:
script/generate migration add_user_inactive_date
which spits out:
11_add_user_inactive_date.rb in db/migrate
So far so good…
Developer B sits down and starts working on feature B.1 which requires a new table to be created. So he also generates a migration:
script/generate migration create_asset_history_table
which I assume spits out:
11_create_asset_history_table.rb in db/migrate
Both developers run their scripts again their local development databases, check in their code, and think that all is right with the world, each with their database schema version sitting at version 11, but each without the other’s changes…
So if this is the way it does actually work then we’ve got a problem, or several:
- Developer A won’t ever get Developer B’s change applied to his database and vise versa.
- If someone goes and roles back Developer A’s inactive date change (by rolling back to schema version 10) then their asset history page will suddenly stop working as it will drop the newly created table as well.
There are probably more issues, but you get the point. So can anyone out there explain how this is handled in Rails?
The funny thing is the only reason this is relevant to me is that I just implemented a similar solution where I work. We started down a very similar path (before I even knew about Rails Migrations) by adding a new column to our AppVersion table to track the schema update date/version. As we got further into the implementation we realized this wasn’t going to cut it. We wound up with a table that tracks every script that has been applied to the database (we use SQL scripts to apply changes to the schema). This allows us to have an ant task that just looks in the directory where these scripts are stored, check the database and then just load scripts that haven’t yet been applied (ordered by date plus an optional sequence number). Ours isn’t so fancy as to have an automated rollback capability, but we’re just happy to have this process automated at all at this point.
Anyway, it’s not something I’m going to lose sleep over and I don’t actively even use Rails, but it’s just been eating at me so I thought I’d throw it out there.
Kevin Clark on 12/20/2005
Scott: Turns out rails will tell you if this happens. I created a testbed app with two migrations with version 2. Here’s the snip.
[Dionysus:~/web/testbed] kevincla% rake migrate
(in /Users/kevinclark/web/testbed)
rake aborted!
Multiple migrations have the version number 2
scott on 12/20/2005
Thanks Kevin, that’s good to know. Like I said in the post, I knew it had to have been considered, but I hadn’t heard it discussed. I still think this might happen a good bit with multiple developers working concurrently (not to mention multiple branches), and that would be a pain. It will be interesting to hear how real teams use it.
Christopher J. Bottaro on 12/19/2007
I wrote a plugin that addresses this issue (and more) with Rails migrations. It works like how your solution does: it creates a schema_info_histories table which keeps track of what migrations have been run. Then it modifies ‘rake db:migrate’ to retroactively run any scripts that haven’t already been run, up until the current database version.
You can read more about it here:
http://blog.stochasticbytes.com/2007/10/better-rails-migrations-retroactive.html
It’s fully documented and comes with rake tasks to examine and manipulate the histories table.
It is NOT tested with Rails 2.x, only Rails 1.2.x.
scott on 12/19/2007
Thanks for the update Christopher. I will definitely check it out.