CODEWITHSUNDEEP
entity-frameworkentity-framework-migrationsef-core-2.0
Maxmanzero
Maxmanzero

Reputation: 319

Entity Framework Core Migrations Separate CI/CD Pipeline

My company is moving to microservices and as part of this shift devops is standing up CI/CD build release pipelines in Azure with VSTS and GIT.

The current model for managing migrations is a developer is given 2 projects in 2 separate git repositories.

Project 1 - API Services project - .NET Framework / .Net Core
Project 2 - Database project based on EF6 using the migration API

These projects have completely independent release pipelines based on the repositories. So when you create a pull request into master the pipeline builds and releases the project.

This new architecture also supports blue green deployments and our app services run on multiple nodes.

The issue we have is that with this set up we have to basically hand code our migrations and can't use any of the tooling provided in EF Core.

Most of the articles and documentation I have read shows running the migrations from app start up, but if you have multiple app service nodes how do you prevent 2 nodes from running the migrations?

Other articles I have looked at show moving migrations into a separate project, but that project needs a reference to the project with the dbcontext in it. In my company's setup this is not possible. Neither can we do the reverse since moving the dbcontext into the database project prevents us from referencing it in the api services project.

Is there any way to support this model with EF Core?

What is the preferred way to implement blue green deployments with EF Core Migrations on a multi node app service?

Upvotes: 5

Views: 2088

Answers (1)

eddyP23
eddyP23

Reputation: 6825

I will try to claim that there isn't and not because EF Core doesn't support it in some way, but because this sounds impossible from what I understood in your question.

Your company want the ability to do blue/green deployments, but it is only really possible on the service layer, but not on database. The idea sounds really cool, fast rollback, almost no downtime. But in reality databases complicate things a lot.

So imagine your Project 1 is running on machines A and B (representing blue and green deployments). A currently is a production environment and B is identical but not serving any requests ATM. Both of them are pointing to the exact same database (if not, it's not blue/green, it's just a separate environment). When you want to deploy your DB changes, you migrate your database, but now both of the machines A and B will be pointing to the updated database. You can keep switching from A to B, but they both might have stopped working if your database migration broke anything.

Therefore I don't really understand what you achieve with having DB migrations in a separate repository with a separate pipeline. This just complicates coordination of the releases as they are clearly dependent, but I don't see how it helps to solve anything. As you noted, you can't delegate creation of migration scripts to EF Core, at least without some manual work.

Would be happy to hear any advantages of such design.

Upvotes: 2

Related Questions