sql – 数据库版本控制 – 如何返回到以前的版本并保留数据？

2019年8月4日 333次阅读

情况

我正在开发一个使用SQL服务器存储数千条记录的Web应用程序.我们目前正在使用源代码控制软件来保存每个版本的应用程序.该应用程序有2个主要版本：

>测试版(我们实际开发的版本)
>实时版(目前在网站上的版本)

我们每个月都会发布一个新的“主要”Live版本,但在那段时间之间,我们可能会在当前的实时版本上发现许多小错误.为了修复这些错误,我们回到Live当前在我们的测试机器上运行的版本(我们使用共享数据库进行测试……).重现错误,找到原因,修复它然后我将补丁应用到我们然后立即推送的错误版本,我们合并测试版本中的错误修复.在每个“主要”版本之间的月份,我们可以发布许多小错误修复补丁.

问题

目前的问题是只有源代码处于版本控制之下;数据库不受版本控制.这是一个问题的原因是,在开发下一个“主要”版本时,许多事情可能会在数据库中发生变化,与先前版本不兼容.因此,即使我们可以返回到先前版本的代码,数据库也无法执行相同的操作,因此除非我们从那时起进行数据库备份,否则我们无法测试以前的版本.

显而易见的解决方案似乎将数据库置于版本控制之下.虽然将数据库模式和静态数据置于版本控制之下并不是真正的问题(我想我会使用Visual Studio Database Project),但我很难看到如何处理用户输入的数据.

这个问题

如何处理用户输入的数据,因为我需要在表格中输入这些数据才能测试应用程序？

>如何使用数据转到以前版本的数据库
此时在数据库中？
>我应该将用户输入的数据置于版本控制之下吗？例如,为我们发布的每个版本使用数据库的完整备份…
>审核是否是保存用户输入数据更改历史记录的良好解决方案？
>是否值得为用户输入的数据而烦恼,因为它只是一个测试版本？我们总是可以手动重新创建测试应用程序所需的所有数据,但这可能需要花费大量时间来测试一个小错误.

最佳答案根据我的经验,我建议一些数据库备份和数据库升级脚本的组合.对于主要版本,您应该保留生产或类似生产数据的备份(您可能有合同义务清除或更改包含客户名称,地址,银行帐号等的数据).从那开始,您应该能够访问数据库的任何中间版本,因为您正在编写数据库升级脚本并将它们保存在源代码管理系统中(您目前正在这样做,对吗？)

出于实际原因,您应该至少有两个独立的QA环境：一个具有数据库模式,应用程序与您的生产环境匹配,另一个与开发中的版本匹配.