Should I merge database migrations together before release?

Question

During the development process many migrations may appear. Is there any point to keep them instead of merging them all together?

Let's take a look into a simple example.

During development we introduce a new model Person:

public class Person {
    public int Id { get; set; }
    public string Name { get; set; }
}

Migration #1 creates a new table Persons with two fields in the database.

Later we decided we need another field - Surname. Migration #2 alters table by adding a new field.

Later we decided to introduce a new related model, so Migration #3 creates new table and alters Persons by adding foreign key.

Later we decided to remove Surname. Migration #4 alters table by removing column.

Later we decided to rename plural form of Persons to Person. Migration #5 removes all foreign keys, laters table by renaming it, creates new foreign keys.

In the end we have a bunch of migrations doing back'n'forth work of creating and removing some fields that we don't need in the final release. Those fields among with some other possible migrations actions are just a part of the history of development, but we don't really need them.

So I was thinking what if I roll back the database to the very first state, remove all migrations and then generate a new one, which will do only nessesary actions to bring a database to it's final state, reducing a possibly huge number of migrations and exessive actions to just one straight forward migration.

Is it a good idea or it is considered an anti-pattern?

Answer 1

This is ok as long as you are 100% sure the merged migrations will never hit a database which is in an intermediate state (so, for example, the Surname column is there, though it should not).

This depends on how well you control your deployment process (especially the deplyoment of the migrations). Note this is not necessarily restricted to production releases - you also need to know which intermediate states you may have in your test environment, and if you have a larger dev team where each dev has his own db for local testing purposes, this might also be affected by the potential state of the different dev environments.

Answer 2

The migrations will be applied automatically when your system deploys. It is very unlikely that DDL commands in SQL dominate the time an installation takes, so the appropriate thing to do is not to worry about this low-level detail of the system. Consolidating them all would require work and contribute virtually nothing to the outcome, so it's the kind of lowest-priority task that you should leave until there's absolutely nothing more urgent to do in the project.

Answer 3

I've see migrations rolled up for deployment in large companies. I would not call it an anti pattern.

EF is a bit of an odd case, but in general you want to be very careful with your DB Migrations. The most common approach I have seen is to regenerate and then hand craft them.

This allows you to Test them against DBs with similar volumes of data to production to ensure that they will function correctly and will not cause any performance issues. Also, you will want to ensure that you have working rollback scripts which can be applied etc

Indeed after you merge them all together you may want to split them again to allow for a phased rollout with backwards compatibility or other requirements.

It's a brave developer who just updates his objects and lets EF figure out what to do with the Production DB. (although tbf MS does a pretty good job of it)