Search code examples
c#gitentity-frameworkredgatedb-first

How to manage db schema changes in different branches when using db first?

I have an Entity Framework 5 DB-First project, which we're just now migrating from TFS to Git. In TFS we kept the DB up to date using RedGate's SQL Source Control, which was an ok way of doing things, assuming that everyone is developing off trunk anyway because branching is so difficult, so pretty much everyone is working on the latest version of the DB schema.

Now that we're on Git, however, I would want the db changes to become part of the feature branch. Since Git allows such easy jumping from branch to branch, I would expect that developers may jump from features including db changes to features without those changes. The code updates so nicely - but what about the DB? I doubt that RedGate's product will handle the up-and-down migrations in such a flash - or am I wrong? And if RedGate can't handle those up and down migrations, what is the correct way of doing it in my code?

BTW, I did search for other similar questions, and found this one, though the answer there is to include the migration scripts in the feature branches. That's all very well for the "up" migrations, but if I'm, say, writing a feature in one branch, then I switch to another branch to do a code review of someone else's pull request, then the changes I made to my local db in my branch should somehow revert. But how?

UPDATE: RedGate responded to a support call by referring me to this article. Basically, if you want to switch branches, you have to unlink/re-link your db from source control. And you can't create or merge branches. In short, ugh. Any better suggestions?

Solution

  • Best solution I've found so far comes from RedGate - their Migrations V2 Beta. You can make your commits in each branch, and when you switch between branches you "Get Latest" on the DB tab to update your local DB to the db schema applicable to that branch.

    It works ok for 80% of cases, but it's not (yet) a perfect solution

    • If you switch branches to a previous version of the schema prior to a migration, there's no way to run a "down" script.
    • The system gets a bit buggy when you have FILESTREAM enabled. I've reported this to their tech support and they've acknowledged the bug, so hopefully this will be ironed out soon.

    Basically, there's a reason why it's called "Beta".

    Anyway, I'm marking this as the solution for now, but if anyone comes up with a better idea, let's hear it.