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

Question

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

但是，我们数据库附带的默认数据经常会发生变化，其中一些数据更新不适合迁移过程。例如，对具有 Identity 主键的表的插入不容易识别，因此在降级时无法撤消。

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

Answer 1

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

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

成功的关键在于我们拥有大量的测试用例，这些测试用例从头开始创建数据库（使用像 H2 这样的内存数据库或安装在每台开发人员机器上的数据库），包括所有数据，然后一路迁移通过和回来。我们可以将生产服务器中的匿名数据导入测试用例，以追踪错误并改进测试，而不会侵犯客户的隐私或妨碍开发人员。