Deploying an EF Migration Zero Downtime? Watch Out!

It is fairly easy to deploy an EF migration without stopping the application, unless we made a breaking change. As this video is demonstrating, the migration, which is a DDL script, is normally deployed in a transaction. It is therefore possible to run it alongside online transactions executed by the running application! Again, unless the change imposed by the DDL script will break the application.
In this video, you will learn a safe way to add a field to the model, and so to add a column to the database table, without causing any service interruption that could be noticed by the users. The prior version of the application will be available through the entire process, all until replaced by the new version and stopped.
This update scheme is fully supported by the Entity Framework Core. It only remains that we, developers, make the steps in the right order, and the most daring part of our daily work - deployment - will work out smoothly.

Learn more from video courses:

Other videos on this channel you may be interested in watching:

#entityframeworkcore #entityframework #dotnet

[mdev]

I'm really impressed with this. I'm still scared if the app is maybe not down when im doing migrations :) Had bad expiriances with it. But I'm still a fan of downtime and making backups :D

[branislavpetrovic]

Great video Zoran! How do you approach to DB versioning? Do you use state versioning, transition versioning or hybrid approach? Do you use tools like DbUp, Fluent Migrator or FlyWay to deploy DB changes on production? Could you do the video about DB versioning and deployment?

Thanks!

[amirmirzababapour]

I really appreciate the video, do you have any thoughts on how such a concept would work if we were to deploy using Kubernetes? How would you run the migration commands in such environment?

[ugochukwuumerie]

Great content, new subscriber here 👋. How do you save the generated script, or do you copy and paste for the CICD?

[jeffersantosss]

The process "Deploy DB changes first and code changes second" only works if the migration is for adding columns or tables. If any columns were removed, renamed, changed type, etc... this could not work as expected.

[miroslavgrozdanovski]

Nice video, but isn't this just saying "deploy DB changes first and code changes second"? Can you give us some examples where the previous version of the code wouldn't normally work with new DB changes and ways to mitigate that problem?