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?
4 Replies
EFC Migrations are always supposed to be added in incremental order
Never never never let two migrations be made and merged in parallel. They need to be added one after the other
If two people work on the DB within two PRs, then the PR who is getting merged second has to bite the bullet, and needs to
- Rollback the Migration from their local db (Update-Database to previous migration)
- Undo the Migration (Revert
XContextModelSnapshot.cs, Delete 20241204.....MigrationName.cs & 20241204.....MigrationName.Design.cs)
- Rebase PR branch to the develop / main branch with the other migration
- Add-Migration now that we have the other migration
- Push / Update PR
One thing however is
You can leave out applying migrations, as long as the migrations were added in incremental order
- 20241201_AddTableX.cs -- Added 01st December
- 20241202_CriticalChangeY.cs -- Added 02nd December
- 20241203_UpdateColumnZ.cs -- Added 03rd December
All of these were Add-Migration'ed one after the other, nicely, but you still need CriticalChangeY for testing, and you cannot afford it to go live on the prod update tomorrow
Then you can simply leave out the commit which added that Migration, via a hotfix / release branch with cherry picking, so that its "Up()" method can never run.
And yes, if you later on add CriticalChangeY back onto your deployed branch, it will work with no problems
We do that sometimes 😉
@Cpt. Reis
The re-doing of the migration with rebasing ain't that bad tbh, unless you have a really really big database project.
Because Remove-Migration & Add-Migration will force rebuild the project before doing the Migration generation magic. Of course, you can force it to not rebuild via a --no-rebuild flag or something, but the default is to let it build the latest version of your code
We have a pretty sizable database project, and when compiling only the Database with no migrations, it takes around 16 seconds
One pain point however of managing EFC Migrations:
Each migration creates and keeps a .Designer.cs which is a snapshot of the entire database, and each migration adds onto the last Snapshot, so it gets bigger and bigger. So after like 30 Migrations it causes our Database project file to bloat up to 1:30 Minutes in compile time. Which is pretty annoying. Not just that, but it hogs up huge amounts of RAM during compilation just because it needs to compile essentially the same huge file again and again.
There is currently no solution to that, and it's only a problem if you've got a huuge database project.
The only workaround is to squash the Migrations. basically eliminating the option to rollback to previous migrations and merging all 30+ Migrations into 1 initial.cs migration.
It's a process that we are planning on implementing regularly at some point, and as far as I have heard, other companies do that too@Monsieur Wholesome
First of all, thank you for your comprehensive answer and all the shared details! Helps a lot! 🙂
I think now it's a bit clearer to me how it's supposed to be used. In our team, we're rather small at the moment, so not much clashes that occur. Yet some new guys will be onboarded soon, and I have a feeling it'll be a struggle (or at least could be)...
The hint without leaving out applying migrations is very useful. Didn't really think of that at all, but might be pretty handy some day!
Any yep, totally agree with you on the last one. Our project isn't that heavy yet, but it'll get more. I do have experience in squashing migrations indeed - we don't have a production yet, and our data is rather easy to restore, so we're more generous when it comes to nuking the databases on test envs and let it be rebuilt - and usually we tend to squash the migrations in the same breath, to keep it all clean and tidy 🙂
As long as you have a policy that enforces PRs, and disallows pushing to dev/develop/main directly, it should be managable, even with the newbies 😄
thank god these standards have evolved 🙂