We have a project that should take about 18 months to go through different developping steps (3 major one). We are at the end of step one.
It is using ASP.Net Core to build a Web API with a mysql database and Entity Framework Core, model first. I have NUnit for mostly integration tests using an inmemory database (I am actually using the sqlite inmemory so It is still a relational database). That is very practical since I don't need a real DB for the automated test part.
We have 3 main environments : dev, staging and prod.
We use bitbucket for the repository with gitflow branches, and a pipeline that does:
- feature branch commit : build and run tests, no deployment,
- dev branch commit : build, launch the tests and then deploy on dev server,
- master branch commit : only when releasing with gitflow, build, launch tests and then deploy on dev server.
Then to put into production, I have to manually launch the deployment from bitbucket.
What I would like : Going from one step to another, there will be update in the DB Schema (and sometime we have to update the data as well with those schema modification). For that, I was planning on using EF Core migration.
To cover the base, I want to be able to test that there no regressions after a migration. For that I would need to be able to:
- start from a database that has the schema before that migration with its test data seeded in it,
- apply the EF Core migration(s) with also data modification if required by the schema changes,
- run all the automated tests.
First step of that would be putting into place the migration system with its initial create migration. In the code, instead of checking/creating the DB with Database.EnsureCreated, we have to use Database.Migrate(). But now my database is acting weird during tests (using in-memory sqlite database, or even just in-memory) and 20% are failing. Looking online, apparently, we can't use apply migration on in-memory database.
I could use EnsureCreated to build the DB for the test, but in production, once we are few steps further, the DB won't be build like that but by multiple migration. Even if the tests are running fine, it might be failing in production since the DB might be different.
Any idea/recommendations on how to solve that problem?