Long term situation of migration files

[Kurira]

We have a project large project maintained by 5+ developers and we started noticing that our deployment packages are getting bigger and bigger. In our investigation we found out that every new migration creates a <MigrationName>.Designer.cs file which includes the whole context snapshot in it (currently 15k lines).

Is this by design? Every migration includes a heavy 15k+ lines commit and our project dll is at 21MB with over 1 million lines just in migration files. I don't see this scaling after 1-2 years of active development.
We would probably have 50-100MB dll. What's the scenario here? Deleting old migrations, because new ones include the latest snapshot anyway?

[bricelam]

How do you use the migrations? Do you use the them at runtime, or are they just used during development and deployment? Are there multiple versions of the application/database schema deployed into production at the same time? Do new devs need to re-create the database locally using migrations?

[bricelam]

Some possibilities:

• You can keep the migrations in a separate assembly that doesn't get deployed.
• You can create two migration sets--one for development and one for releases. The one for releases would presumably be smaller than the one for development.
• We don't have tooling for it yet (Squash migrations #2174), but you can combine/squash older migrations together into a single migration.
• Taking squashing to the extreme, you can delete all the migrations and start fresh. After deleting them, create a new one, comment out the contents of the Up method, run Update-Database to mark the migration as applied, uncomment the Up method so new devs can still create the database.