渐进式数据库迁移和默认数据

Question

我们正在重新评估我们的应用程序的数据库升级过程，以尝试消除在发布周期结束时必须为发布生成所有升级脚本的痛苦。我们正在寻求一种更进化的过程，使用迁移，通过migratordotnet等工具与功能一起签入，这似乎是管理模式更改的一种非常干净的方式。

然而，我们的数据库附带的默认数据经常会发生变化，其中一些数据更新并不适合迁移过程。例如，对具有标识主键的表的插入不容易识别，因此在降级时不能反转。

所以我想知道人们是如何管理默认数据的迁移的？他们是否在方案迁移过程之外对其进行管理？或者在迁移期间执行插入，但在降级期间不执行数据删除？

Answer 1

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

降级很少是问题，但如果有问题，请创建一个包含版本信息的列。当升级成功并且客户决定继续使用新版本时，再次删除该列(或保留它)。

成功的关键是我们有大量的测试用例，可以从头开始创建数据库(使用内存中的DB，如H2或安装在每个开发人员机器上的DB )，包括所有数据，然后一直迁移并迁移回来。我们可以将匿名数据从生产服务器导入到测试用例中，以跟踪错误并改进测试，而不会侵犯客户的隐私或妨碍开发人员。