Proper usage of EF Core in teams?
hi all!
i dipped my toes into the world of .NET half a year ago (coming from the Java ecosystem). and so far, i like it quite much.
but one thing that keeps me struggling - EF Core. while i understand its power and benefits, it seems to be hard to use it in teams, especially when teams get larger and DB-involving features are implemented concurrently.
- the context model snapshot is something that always brings merge conflicts, and a little mistake when resolving them may cause a dangerous inconsistency
- the timestamps of the migrations can be a problem, especially if a "newer" feature is merged before an older one, and the timestamps are in wrong order then
- if you deploy stuff including DB changes to testing environments, e.g. new columns remain there, even if a different branch without those changes is deployed at a later point. that would require more maintenance because you'd have to configure CICD to do a rollback or something... you could also drop the db and recreate, but if you have environments that have some complex test data present, you would probably want to avoid such a nuke
maybe i'm just missing out something and it feels harder to me than it actually is.
but how is EF Core supposed to be productively used within teams, while avoid a lot of additional work?
i dipped my toes into the world of .NET half a year ago (coming from the Java ecosystem). and so far, i like it quite much.
but one thing that keeps me struggling - EF Core. while i understand its power and benefits, it seems to be hard to use it in teams, especially when teams get larger and DB-involving features are implemented concurrently.
- the context model snapshot is something that always brings merge conflicts, and a little mistake when resolving them may cause a dangerous inconsistency
- the timestamps of the migrations can be a problem, especially if a "newer" feature is merged before an older one, and the timestamps are in wrong order then
- if you deploy stuff including DB changes to testing environments, e.g. new columns remain there, even if a different branch without those changes is deployed at a later point. that would require more maintenance because you'd have to configure CICD to do a rollback or something... you could also drop the db and recreate, but if you have environments that have some complex test data present, you would probably want to avoid such a nuke
maybe i'm just missing out something and it feels harder to me than it actually is.
but how is EF Core supposed to be productively used within teams, while avoid a lot of additional work?
