Vita Rara: A Life Uncommon

How I Use Rails Migrations for a New Project


Yesterday I started a new Rails project and it got me thinking about how I use migrations at the start of a project. I generally start with models and migrations when I begin a new project.

My usage of migrations tends to differ in the first day(s) of a Rails project. I will frequently roll the version of the data schema between 0 and the current version. I do this because if I forget a field/property on a model I don't define a new migration to add it, I just roll the schema back to 0 (rake db:migrate VERSION=0), change the create table migration, and then do a rake db:migrate to bring the schema right up to date. I find this the most pragmatic method early on and I continue to use it until I can't.

Why do I do this?

  • Most of the fields in my model end up in one migration file.
  • Having most of the fields in the create table migration helps my comprehension of the model. (I know I can look at schema.rb, or a SQL definition, but those don't have comments in them.)
  • It keeps the number of migrations files small. Generally I only have one create table migration for each model when I get started.

Later as my project evolves I will use subsequent migrations to add/remove fields from tables, rename fields, etc.

How many developers do you have?

Does this scale to a team of, say, 5 non-colocated developers? It very well might thanks to version control, but I'm just wondering what your experience is.

Haven't used a large team yet.

We're a small house. Four full time developers. I generally lay down the foundation and then work other developers into it. So, no I haven't done this with a team on non-collocated developers. With that said I think using a version control system would allow this style of usage while a base schema is worked out.