How to manage Migrations in a project with multiple branches?

前端 未结 7 607
情书的邮戳
情书的邮戳 2020-12-12 11:39

I have an ASP.NET MVC3 project that uses Entity Framework 4.3 with the code-first approach. I use Migrations to keep the database up-to-date.

The project is under so

7条回答
  •  没有蜡笔的小新
    2020-12-12 12:09

    Merging migrations is IMHO manual task. Part of migration code is auto-generated and we usually don't merge auto-generated code - instead we run autogeneration again after the merge.

    Until ADO.NET team provides some recommendation I would follow simple principle:

    • Before you do the merge revert the master database to the version used prior to branching
    • Merge your branches
    • Exclude migration classes created after branching from merged assembly
    • Add a new migration for merged code base which will migrate your database in the state prior to branching to the state after merging branches
    • If your excluded migration classes contain some customization merge them to the new migration class
    • Run migration to migrate your database to current merged version

    If your branches contained multiple migration steps (version) you will lose them and you will end with two versions - prior to branching and after merging.

    Edit:

    It will not work in live environment. The problem here would be the development process itself. If you have live environment you should keep its branch untouched (except minor bug fixes). If you continue development in that branch with production deployment and in the same time you build another version in separate branch without continuous integration (= continuous merging changes back to the main branch to integrate your new development with the main code base) you have a big problem. I think migrations in general cannot handle this.

    The only option in such case would probably be removing all migrations from merged solution and deleting MigrationHistory table from the database. Than you can enable migrations on the project again and add initial migration to use your current database as starting point = no way back to previous version because no information about previous migrations will exist.

提交回复
热议问题