Using Code First concept of Entity Framework in production

Question

I'm developing an application and I have a database with it using Entity Framework Code First concept. I like this approach very much. I'm using the latest version of EF which is 6.1.1.

My main concerns are how to deal with database changes without losing data. I've done quite a few changes and a few of those changes gave me a hard time during the migration process. I just had to delete the database and start over again with the Seed() etc.

My question is, can I/should I use Code First in production for a serious business application or not? The database schema isn't that big, around 20 tables and less than a half of them are just lookup tables.

This question kind of has been asked before (see this post), but EF has been evolved a lot since than. And I'm struggling with this question quite some time now. I could really use some peace in my mind and a good night rest.

Answer 1

The answer is YES, of course, you can use Code First in production. I have seen a lot of projects that succeed in it. You could use EF's migration engine: there are lot of examples around. Or you could give a try to another migration framework, like FluentMigrator.

And there is no danger of using migrations in production if you follow good practices in deployment: e.g. you have DEV, STAGE servers where you could test your migrations before production, + you make backups of database before each PROD release. Ideally, when all these processes are managed from your Continuous Integration server.