13

I have always found version control a bit of an issue when it comes to database schemas.

So - I am currently evaluating Entity Framework Code First Migrations and so far I'm really impressed.

My question is, does anyone have any experience of using Migrations in a team using a DVCS?

If developers working on different branches each create their own Migrations, does the 'Update-Database' tool cope well with that when the branches are merged?

I guess what could happen is that a new Migration would appear in the middle of the list. Would this then get picked up, or does it just look for 'newer' migrations than the last one deployed?

I appreciate the team are going to have to be careful not to create conflicting schema changes - this is something we can manage - but it would be useful to know if 'Update-Database' is smart enough to spot the 'missing' migration?

Thanks, - Chris

Chris Roberts
  • 18,622
  • 12
  • 60
  • 67

3 Answers3

1

According to the one blog post I could find on the topic, it seems that parallel development, regardless of the VCS tool, is problematic with the current state of database migrations in EF. There doesn't seem to be a way to handle the scenario due to how it tracks state of the database. Pawel provides an example project on GitHub to display the issue.

You may actually be far better off using an independent tool to handle your database migrations. I have used Migrator.NET with a great deal of success and it does properly handle parallel developers' schema changes. It also uses a relatively low-tech method of tracking the database "version," which surprisingly works very well as long as you and your team decide on the day that nobody will ever touch the database except through a migration class (we called that day v1 of the database).

Sumo
  • 4,066
  • 23
  • 40
  • Look at [FluentMigrator](http://nuget.org/packages/FluentMigrator) as well. Seems Migrator.NET went stale and this project has so many similarities. I fired it up last night and it even has a way to use existing Migrator.NET migration classes. – Sumo Sep 27 '12 at 18:29
1

The solutions in this article might work for you. You take an extra step of creating a blank migration that ignores the changes from the other developer. This updates the snapshot to be in sync with the database.

http://msdn.microsoft.com/en-us/data/dn481501.aspx

Dan
  • 802
  • 1
  • 9
  • 19
0

I don't think it works and I don't think there's a way around it.

See this blog post for more details.

My recommendation would be to use a different tool to manage your migrations.

Krzysztof Kozmic
  • 27,267
  • 12
  • 73
  • 115