ORM Code First versa Database First in Production

Question

I have been using SQL since 1985, so am very comfortable with DB servers.
I see (C#) Code First as yet another fad, that comes and goes. It seems to suit people that have no DBA background. Equally if using Code First and you have not idea what DB you are connecting to eg it might be Mongo later that too is a useful abstraction. Code First does not let itself to Database Diagrams so you can see what is going on.
I would like to know how you promote changes into a production SQL server using code first, where you have no desire to Drop and recreate the DB, unlike using an ALTER TABLE command. I have used tools from Red-Gate that make DB code promotions easy. So why Code First? How do you move DB Changes into production?

Answer 1

The code first approach is something that is really nice to have when you're prototyping applications and "don't care" about the "persistence layer" too much in the beginning. It helps getting quick results in a time when things are not at all well defined yet, because you can always very easily drop and re-create your database of your greenfield project.

Unfortunately, most tools that offer this approach do not really help transitioning from the "greenfield project mode" to the more longterm "legacy project mode" where database migrations are essential. In fact, not only are database migrations difficult to achieve in "client model first" approaches, but more importantly, the likelihood of the database model not being well designed is quite high.

Developers pay a high price for the quick win - as always. It is really not a good idea and a lot of more experienced developers who are used to working with legacy, do agree with you: Go database first, and derive your client (e.g. ORM) models from it.

I have written about this topic here, including the advantage of using client model source code generation.