我们正在重新评估我们的应用程序的数据库升级过程，以尝试消除在发布周期结束时必须为发布生成所有升级脚本的痛苦。我们希望采用更加进化的流程，使用与migratordotnet等工具一起检查功能的迁移，这似乎是管理模式更改的一种非常简洁的方法。
但是，我们数据库附带的默认数据经常会发生变化，其中一些数据更新不适合迁移过程。例如，对具有Identity主键的表的插入不易识别，因此在降级时无法撤消。
所以我想知道人们如何管理默认数据的迁移？他们是否在计划迁移过程之外进行了管理？或者是在迁移期间执行的插入，但在降级期间不执行数据删除？
答案 0 :(得分：3)
对我们来说，数据库迁移是日常开发过程的一部分。开发人员必须提交程序或执行必要更改的脚本。这种情况会在相关功能实施后立即发生，并且永远不会“在发布周期结束时”。
降级很少是一个问题，但如果你有，请创建一个包含版本信息的列。当升级成功并且客户决定继续使用新版本时，请再次删除该列（或保留该列）。
成功的关键是我们有大量的测试用例，从头开始创建数据库（使用内存数据库，如H2或安装在每台开发人员机器上的数据库），包括所有数据，然后一路迁移通过和回来。我们可以将生产服务器中的匿名数据导入测试用例，以便在不侵犯客户隐私或妨碍开发人员的情况下追踪错误并改进测试。