情况
我正在开发一个使用 SQL 服务器来存储数千条记录的 Web 应用程序。我们目前正在使用一个源代码控制软件来保存应用程序的每个版本。该应用程序有两个主要版本:
我们每个月左右都会发布一个新的“主要”实时版本，但在那之间我们可能会发现当前实时版本的许多小错误。为了修复这些错误，我们回到 Live 当前在我们的测试机器上运行的版本(我们使用共享数据库进行测试……)。重现错误，找到原因，修复它，然后我将补丁应用于有错误的版本，然后我们立即将其推送到现场，我们将错误修复合并到测试版本中。在每个“主要”版本之间的一个月内，我们可以发布许多小错误修复补丁。
问题
目前的问题是只有源代码在版本控制下；数据库不受版本控制。之所以会出现这个问题，是因为在开发下一个“主要”版本时，数据库中可能会发生许多与以前版本不兼容的变化。因此，即使我们可以回到以前版本的代码，数据库也不能这样做，因此除非我们有当时的数据库备份，否则我们无法测试以前的版本。
显而易见的解决方案似乎是将数据库置于版本控制之下。虽然将数据库模式和静态数据置于版本控制之下并不是真正的问题(我想我会使用 Visual Studio Database Project )，但我很难看到如何处理用户输入的数据。
问题
由于我需要在表中输入此类数据以测试应用程序，因此如何处理用户输入的数据？
此时在数据库中？
最佳答案
根据我的经验，我建议将数据库备份和数据库升级脚本结合起来。您应该为主要版本保留生产或类似生产数据的备份(您可能根据契约(Contract)有义务清除或更改客户的姓名、地址、银行帐号等数据)。从那开始，您应该能够获得数据库的任何中间版本，因为您正在编写数据库升级脚本并将它们保存在您的源代码控制系统中(您目前正在这样做，对吗？)
出于实际原因，您应该至少有两个单独的 QA 环境:一个具有与您的生产环境匹配的数据库架构和应用程序，另一个与正在开发的版本匹配。
虽然数据库备份很大，但您只需要保留一些最新的备份，除非您预计需要对已废弃多年的版本进行一些事后错误分析。