Efcore: Team-environment migrations - EF Core equivalent?

[kierenj]

We're discussing our strategy for migrations moving forward here. Long-time fans of automatic migrations during initial build, then explicit migrations from first release.

Have now seen that automatic migrations were removed, and have read the various issues/debates, and http://www.bricelam.net/2014/12/16/ef7-migrations-designtime.html .

As per @divega's comment here https://github.com/aspnet/EntityFramework/issues/6214#issuecomment-272062893 - perhaps @rowanmiller (edit: oops.. or someone else!) or someone wouldn't mind suggesting the intended/advised approach for parallel working w/EF models?

Do I have it right that, as per that first link, it's just a case of using source control diffing/merge conflict resolution? Are migrations no longer "sequentially tied", for instance if two developers add their own migrations with different timestamps, when the second developer pulls and Update-Databases, there's no issue - the earlier migration will run, despite his later one being in place already?

[bricelam]

Are migrations no longer "sequentially tied", for instance if two developers add their own migrations with different timestamps, when the second developer pulls and Update-Databases, there's no issue - the earlier migration will run, despite his later one being in place already?

Correct. Developers just need to ensure the model snapshot is merged correctly when they pull. This avoids most of the issues we saw with team environments in EF6.

You can still hit conflicts that are harder to resolve (e.g. Dev1 renames "A" to "B", but Dev1 renamed it to "C") but while merging the model snapshot these more serious cases will become apparent. The easiest way to resolve these conflicts is to:

1. Revert and remove the local migration
2. Pull the conflicting changes
3. Re-add the local migration

[bricelam]

...automatic migrations during initial build, then explicit migrations from first release

If you want to keep the "release" set of migrations minimal, you can use two migrations sets--one for development and one for releases. Do this by putting each set of migrations in its own assembly and configure it using MigrationsAssembly.

C# optionsBuilder.UseSqlServer( connectionString, x => x.MigrationsAssembly("MyApp.DevelopmentMigrations"));

[kierenj]

Thank you @bricelam. That does make sense. Just so I can use the correct terminology, "model snapshot" = the code model?

With regard to your suggestion of separate assemblies - very interesting! I'll have to think how that fits in with our release process/strategy.

One issue we've run into with some long-running, long-maintained EF projects is that there's maybe 48MB of migrations base64 resource data built up. It's great that that's not an issue moving forward. But, I guess things will still grow over time with a slight performance implication: any migration applied to live is there for good, and the history table will always be checked to see if that list matches classes in the mig. assembly?

[bricelam]

The model snapshot is a new artifact that gets (re-)generated every time you add a migration. It's typically found in the Migrations directory.

We no longer use resources in EF Core. These were a serialized form of the target model. We now use compiled calls to ModelBuilder to store them.

[kierenj]

Ah right - I had seen that before but must have forgotten about it. Looks great and makes sense. Thank you for the discussion.

[bricelam]

Please let us know what pain points you encounter while using Migrations in team environments. Improving this experience was the main motivation behind the architectural changes to Migrations in EF Core.

[stap123]

@bricelam Is there any official documentation/walk throughs about this? Would be useful to help people understanding it for the first time?

[bricelam]

EF Core Migrations in Team Environments