1

We're a small development team of about 8 developers working on an ASP.NET MVC 5 and Web API 2 application. Our team is divided up into front-end (AngularJS) and back-end developers.

Our application runs on 2 servers -- Staging and Production -- while active development is on our local machines.

Develop has the newest Entity Framework migrations.
Staging is a little behind on Develop.
Production is behind on Staging.

So we have 3 database-states, Production being the oldest.

Our issue now is that we have 70 migration files, going all the way back to June 2014. Some lesser colleagues have also botched up a few of them, so the history feels very shaky to say the least.

My plan is to reset the migrations. A tricky feat because of the above mentioned versions. We regularly merge branches so we don't want to mess things up.

Thinking about a strategy I feel like I should migrate back to the last successful migration that was performed on Production, since that is the migration history trailing everything else.

Can somebody with experience explain to me how this can be done safely? Maybe somebody has a link to a good article on the subject?

I don't mean standard "How to reset migration history" articles. We're interested in doing it in a team environment and with various versions active.

Fred Fickleberry III
  • 2,439
  • 4
  • 34
  • 50
  • Here are some relevant articles: 1) Migrations in team environment https://msdn.microsoft.com/en-US/data/dn481501?f=255&MSPPError=-2147217396 2) Similar SO question http://stackoverflow.com/questions/13314725/migrations-in-entity-framework-in-a-collaborative-environment 3) Rolling up migrations http://cpratt.co/migrating-production-database-with-entity-framework-code-first/#at_pco=smlwn-1.0&at_si=54ad5c7b61c48943&at_ab=per-12&at_pos=0&at_tot=1 – Steve Greene Dec 02 '15 at 14:56
  • 2
    Give the post on my blog Steve linked to a read. TL;DR, migrations are really only workable in development and even then, only for the developer who creates them. I wouldn't recommend actually committing migrations, and you definitely shouldn't use them against anything other than a development database. By virtue of receiving updated entity classes, other developers on the team will be prompted to generated a migration against their development database. – Chris Pratt Dec 02 '15 at 15:12
  • Another option I've discovered is generating a single, idempotent, script that will check if each migration has been applied and skip the ones that have. This of course assumes you have __MigrationHistory table in your database which some DBAs frown on. https://msdn.microsoft.com/en-us/data/jj591621.aspx?f=255&MSPPError=-2147217396#idempotent – Steve Greene Dec 02 '15 at 21:15
  • @ChrisPratt: your approach makes much more sense; use migrations for development use, but generate SQL scripts for the DBA to execute on a production DB. --- Is this view adopted by development teams today? It's hard to find any information on this strategy. – Fred Fickleberry III Dec 03 '15 at 08:44
  • I can only speak to my personal development experience, but as far as that goes, yes, this is pretty much standard practice everywhere I've been. Migrations are nice, but they're far too brittle, especially in a team environment. – Chris Pratt Dec 03 '15 at 13:44

0 Answers0