Going with code-first migration and entity framework

Question

I Need advice in how to manage code-first migrations with large back-end database and many developers working with distinct but related entities/tables. I have seen project leaders deleting MigrationHistory table in the past due to hard to resolve inconsistency between model and database version. I dont want to have to do such things in my next project.

To those who have successful histories in the matter will be good if they share your experience on what should do and what should not be do, to avoid coding my self to a corner.

Answer 1

Code-first migrations can be tricky for even a single developer. I think the key is to have one designated person to approve changes to the database model before creating a new migration, and especially before performing "update-database."

If this is not practical for a database with a lot of tables, designate a group leader over subsets of related data tables.

Make sure your project leaders understand how to target earlier migrations with "update-database." It was a little daunting for me to learn but I really like it now.

Answer 2

The gold rules that allowed me succeed in this task:

1. Each team member should have a local development database
2. Avoid automatic migrations

Source: Code First Migrations in Team Environments - MSDN