Managing EF Code First Migrations between Development and Production

Question

Very briefly:

I was implementing EF Migrations on an existing project built as Code First based on an article by Ladislav Mrnka

When implementing EF Migrations on a project that is already into production, how can Migration scripts be managed between updates applied to Development and then Scripts generated for Production?

The reason I'm baffled is that the MigrationId generated for each script had a TimeStamp appended to it. In my migration attempts, I noticed that the entries recorded within the __MigrationHistory tables on dev and prod were different, thus raising the question, if the DB were to go through quite a few Migration Upgrades, then if ever a Downgrade was required for any reason, It would be very difficult to co-relate the exact MigrationId for creating the scripts using update-database -script

---

Very straight forward process where you create an $InitialMigration that creates the __MigrationHistory table. Then any changes to your Model are followed by any update-database to get the database Migrated. And this process cycles whenever you have a logically grouped batch of Model changes.

A look into the __MigrationHistory table showed

+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+
|            MigrationId             |        CreatedOn        |                              Model                               | ProductVersion |
+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+
| 000000000000000_BootstrapMigration | 2012-03-01 17:40:39.567 | 0x1F8B08000000400ECBD07601C49...HASH_TRUNCATED...CA7F54A20F50000 | 4.3.1          |
| 201203011745335_AutomaticMigration | 2012-03-01 17:45:33.557 | 0x1F8B08000000400ECBD07601C49...HASH_TRUNCATED...F4AE3681EF50000 | 4.3.1          |
+------------------------------------+-------------------------+------------------------------------------------------------------+----------------+

Answer 1

According to your comment it looks like the solution is straight forward. If you want to have same timestamp you must use Update-Database only once and in your case it means using:

Update-Database -Script

and executing created script on both databases.

Anyway I would probably not use automatic migrations in scenario where I expect downgrades. I would use code based migrations with explicit name for every migration. In such case every record in MigrationHistory table should have unique name and timestamp should not matter.