We're just starting off with using Entity Framework Code First approach and I'm playing with the Code Migrations system.
So we were wondering, are the migration files intended to be treated as generated code and shouldn't be modified or are they supposed to be generated for you as a scaffold and then you can add extra things like default values and extra data to it?
Just because starting off it seems like it is quite easy to have your database get out of sync if a migration was done incorrectly and the Down() methods doesn't necessarily clean up the Up method. And the problem is you can't really know whether it works until you actually need to reverse the migration.
In addition, should migrations ever be changed, deleted or re-scaffold-ed if they've been checked in and definitely if it's been elevated to an upper level environment? Because I can see Team Member A checks in a migration, then Team Member B checks it out and runs it, if Team Member A modifies it now, then they both would have different versions of the databases and there may not be an easy way to reverse it as the migration files have all changed.
It seems Code Migrations seem like a powerful technology but there are situations where databases can get out of sync with the migration process and therefore it seems in a team requirement, there needs to be some rules in place.
What are the best practices to ensure that Code Migrations work well in a team environment?
Best Answer
The
add-migrationliterally says it's scaffolding the class for you. You can certainly go in and add things, though extra data is better done via the Seeding stuff available in the DbContext Configuration.In general though, I would never modify them once checked in. And I wouldn't really count on them being reversible if you modify them at all. If you screw up, and need to make a fix then you get to make a new migration to do that.
From what I've seen, they're best treated as one-way modification scripts that EF will nicely order and optionally execute for you.