1

I have a .NET application that is using EF Core as ORM, and all db modifications are done using Db Migrations in EF.

The application is hosted on the cloud on multiple VMs in production, after do all testing, a rolling deployment is initiated to take one VM at a time, deploy the new application, and so on.

The database itself hosted on managed Db service (Like aws RDS, Azure SQL) with multi-az/replication setup.

The main goal, is to make sure there is no downtime (0 downtime), and rollback if any issue happened (or manually distribute canary weighted requests accordingly)

the main issue is, if application successfully deployed to one instance, and that instance receives a connection, this will cause the database to be migrated to the new version, causing all other instances requests to fail (as EF will have different migrated db in the old instances)

Mustafa Magdy
  • 1,230
  • 5
  • 28
  • 44
  • I could be wrong, but I don't think they will fail. Unless you've dropped or renamed columns. – hyperdrive Jun 15 '21 at 05:24
  • @hyperdrive Unfortunately, because EF validates schema on start, it will find that this differs from the current version and will fail – Mustafa Magdy Jun 18 '21 at 18:36
  • I think recommended approach is to run migrations from [migrations scripts](https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/applying?tabs=dotnet-core-cli) in the pipeline, not auto-migration on app startup. Maybe I don't understand, but the other instances have already started, why would they restart? Should be fine as long as nothing has been dropped or renamed obviously. – hyperdrive Jul 12 '21 at 17:23

0 Answers0