Great question! Deciding how to fit any ORM (including EF Core) in with database development and CI/CD practices depends on a couple of factors, including:
- do developers need or want to review the database changes proposed by the ORM for quality or correctness? One approach can be to automate the generation of a SQL project from a database generated by EF Core in a CI pipeline (sqlpackage /a:extract /p:ExtractTarget=sqlproject), which would give you source controlled visibility to the actual T-SQL objects and the ability to apply sql code analysis before antipatterns make it downstream.
- how mature/old is the application? A long history of migrations may be causing slower deployments or difficulty in pinpointing what will actually run at this point, and compressing/consolidating them can be challenging for some teams. Getting a single customized deployment script per environment can be worth the time to setup either reverse engineering to a SQL project or extracting a dacpac from a staging environment.
- is the application deployed to 1, 5, 100, or more environments? The more complex/sophisticated the infrastructure requirements, the more meaningful being able to deploy just-in-time changes and checking for environment drift become.
- do database-focused developers or DBAs apply object changes or fixes further in the app dev lifecycle? For example - adding/modifying indexes or changing stored procedures. SQL projects provide a way to create a single source of truth for the database environment that multiple people/teams can share.
This presentation from 2025 focused on the ways SQL projects can support development, including development using EF Core: https://www.youtube.com/watch?v=4P1cSyKiYVw
Microsoft
