Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

EF Core migrations in Docker container

ayi

<r>I am setting up a WebApi in .NET Core 2.0. I will be using Entity Framework Core as ORM. Whole app will be deployed as Docker Container. The thing that disturbs me a bit is the way of handling DB migrations in this case. I mean PRODUCTION environment. Here is what I managed to research:

We just fire Database.Migrate() in the app start forgetting the whole world- hmm somehow I don't like it <E>;-)</E>
Database.Migrate() driven by command-line param (run docker container once with a specified param to migrate DB)
Log into application container and execute dotnet ef database update
Generate plain old SQL based on migrations and execute it from DB management tool. Seems oldschool but valid. The thing I hate is to mess with executing scripts on my own.
Prepare a Database container that would already have scripts generated from code above, and that would automatically execute them. 
 
Any other suggestions ? Or what is the best, most proper solution ? 
 
Regards</r>

ayi

<r>In my opinion, it is your first point (Database.Migrate() due startup) that meets mostly our use case. So for me, it`s currently the preferred way to do that. 
 
We have some additional constellations in the starting up process:

Docker container locally only (for dev environment and testing for sure)
Own startup project which executes the Database.Migrate() part (cause we have more than one project with its own database)
Additional project with the actually API website <E>🙂</E>
Production environment with Azure SQL server (Published and deployed through Azure DevOps pipeline
Migrations are created in its own project via dotnet ef ... 
 
dotnet ef migrations add "your migration name" --startup-project "path to your actually API" --context "database context name" 
 
Important: 
you have to change the working directory to the migration project first in order to use another startup project but generate the migration files in the "migration project" 
 
In our case, it works fine with different APIs with their own databases behind the scene. 
 
Regards</r>