Currently the API is responsible for applying database migrations via the context during startup. This worked perfectly fine for a monolithic architecture where we knew that the API was the only point of access for the database. Now that we are deploying multiple microservices that will be accessing the database independently of each other, this method can create problems if a microservice is expecting a certain database schema before the API is able to perform a migration during deployment (think race conditions). This specific strategy is documented here in the EF Core documentation.
[x] Identify a strategy for applying new migrations during deployment
[x] Integrate new strategy into deployment
[x] Test new strategy
[x] Remove existing code for applying migrations within the otr-api
Currently the API is responsible for applying database migrations via the context during startup. This worked perfectly fine for a monolithic architecture where we knew that the API was the only point of access for the database. Now that we are deploying multiple microservices that will be accessing the database independently of each other, this method can create problems if a microservice is expecting a certain database schema before the API is able to perform a migration during deployment (think race conditions). This specific strategy is documented here in the EF Core documentation.
otr-api