EntityFramework code based migrations, how is order determined?

Question

I'm using EF 5.0 and I would like to start using Code-based migrations

I've used fluent migrator and there is a concept of migration order. Migrations can be migrated/rollback no matter the database's migration version.

Does Entity Framework have similar functionality?

I was planning on keeping multiple migration implementations for each database version (likely tied to sprint number at first).

Why do i want this?

Our continuous integration will migrate the database for each environment. It's likely that our Dev build will only be one version "behind" but when we go to QA or PROD environment the database will be behind by multiple migrations.

Maybe i'm going about this the wrong way, in which case I would love to hear opinions on the best way to do migration with CI.

Wangle

Answer 1

Yes EF has this functionality.

When you run Add-Migration you'll notice the migration file is prefixed with a timestamp. This is what determines the order, assuming automatic migrations are and always have been disabled.

If you are using a mixture of explicit migrations and automatic migrations then you may notice an additional Source property in the .resx file generated with your migration. This is how EF will determine if it needs to run an automatic migration before it runs your explicit migration.

My experience has taught me these guidelines:

1) Never use automatic migrations.

2) Every developer on your team should ensure they have the latest code before creating a new explicit migration. Sort of obvious, but creating migrations from stale code will result in problems.

3) Developers should make sure that if they write custom SQL in the Up() method of the migration then they write appropriate code (and test it!) to reverse those changes in the Down() method.

Basis

Good points, cheers. I would say 2) is not obvious until you realize that EF has a binary representation of the current model stashed away which is impossible to merge/update. (See also https://mcmap.net/q/750110/-how-are-the-compressed-models-stored-in-the-ef-4-3-code-first-migrations-__migrationhistory-table-created ) So much for feature branches :-/ – Lavonda

I think you can still use Feature branches, just before your feature goes in, rebase to get their code, roll back your migrations, and recreate your migration, using their new snapshot (and get in quick before someone else commits something!) – Killian