CODEWITHSUNDEEP
ruby-on-railsversion-controlmigration
Rudd Zwolinski
Rudd Zwolinski

Reputation: 27611

How do you manage Ruby on Rails migrations with a team of developers?

We have a team of developers who are each going to be developing database migrations for our system using the Rails tools. Migrations seems at first like a great way to manage changes to the database schema, but as we go on it has become harder to manage changes in a distributed way. If we each develop migrations on our own, how can we reconcile the problems that occur?

To be specific about the problems, imagine the following scenario timeline:

  1. Developer A creates a new migration file timestamped with 9:00 a.m.
  2. Developer B creates another new migration file timestamped with 10:00 a.m.
  3. Developer B checks in the migration dated 10:00 a.m. at 11:00 a.m.
  4. Developer A checks in the migration dated 9:00 a.m. at 11:30 a.m.

There are a number of problems that can occur here, especially if the two migration files conflict in their changes, but the most basic problem is that some people have run the 10:00 a.m. migration when the 9:00 a.m. migration is checked in. The timestamps associated with the migrations are of course when the file was created, not when it was checked in, which will mess up the Rails migrator.

This is a fixable problem, but the solution could be plenty of different options. What is the best way (or at least a good way) to solve this problem?

Upvotes: 3

Views: 1207

Answers (2)

Ariejan
Ariejan

Reputation: 11079

We always create a bootstrap rake task. This task drops the development db, runs all migrations in turn and then fills it with bogus testing data.

Besides having tons of content in your app to use, you also have to run all migrations. If you do this before you commit your stuff, you're sure all migrations will work for others as well.

Upvotes: 0

hgmnz
hgmnz

Reputation: 13306

This seems more like a team communication problem, or a plain process problem. The migration versions where changed from sequential numbers to timestamps to avoid the problem where developers A and B create a migration with the same version.

In order to avoid migration conflicts:

  • Always keep the team on the loop when it comes to creation of migrations. That should avoid the problem alltogether.
  • Always pull from your repository and test migrations (and run your test suite) before checking your code changes back into the main shared repo. This is a safety net that should always be followed.

Now your scenario looks like this:

  1. Developer A creates a new migration file timestamped with 9:00 a.m.
  2. Developer B creates another new migration file timestamped with 10:00 a.m.
  3. Developer B pulls from repository. Realizing there are no new changes, checks in the migration dated 10:00 a.m. at 11:00 a.m.
  4. Developer A pulls from the repository, runs migrations and test suites, resolves any conflicts and pushes to repository at 11:30am (ok, maybe 11:35).

Never push to a shared repo without making sure your changes won't introduce a conflict or break the build.

Upvotes: 6

Related Questions