演化数据库迁移和默认数据

Question

我们正在重新评估我们的应用程序的数据库升级过程，试图消除在发布周期结束时必须生成所有发行版升级脚本的麻烦。我们正在寻求进一步发展，使用与诸如migratordotnet这样的工具一起检查功能的迁移，这似乎是管理模式更改的一种非常干净的方式。

但是，随我们的数据库一起提供的默认数据会经常发生变化，其中一些数据更新与迁移过程不相符。例如，对具有Identity主键的表进行插入不易识别，因此在降级时不能反转。

所以我想知道人们如何管理默认数据的迁移？他们是否在计划迁移过程之外管理它？或者是在迁移期间执行插入操作，但在降级期间不会执行数据删除操作？

Answer 1

对我们来说，数据库迁移是日常开发过程的一部分。开发人员必须提交执行必要更改的程序或脚本。这种情况发生在相关功能被实现后，并且从不“在发布周期结束时”。

降级很少成为问题，但如果您拥有它，请使用版本信息创建一个列。当升级成功并且客户决定保留新版本时，再次丢弃该列（或保留该列）。

成功的关键是我们有大量的测试用例，它们从头开始创建数据库（使用内存数据库（如H2）或安装在每个开发人员计算机上的数据库），然后将其全部迁移通过和返回的方式。我们可以将生产服务器中的匿名数据导入测试用例，以追踪错误并改进测试，而不会违反客户的隐私或妨碍开发人员的工作。