数据库修改脚本-发布/回滚最佳实践？

Question

4

我正在寻求关于软件系统中与其他代码更改一起发布的数据库脚本修改的最佳实践见解。

我曾经在一家公司工作，他们坚持每次发布都有一个回滚，以防出现问题。这听起来很明智，但在我看来，通过脚本部署的数据库修改的回滚代码和发布脚本具有同样的失败可能性。

对于托管的代码，版本控制使这变得非常简单，但对于数据库架构，回滚更改并不容易 - 特别是如果数据作为发布的一部分进行了更改。

我的当前做法是在后期开发阶段针对测试数据库运行发布代码，然后针对该测试数据库运行应用程序。之后，我备份现场数据库，并继续进行发布。

我还没有遇到问题，但想知道其他商店如何管理数据库更改以及从任何错误中恢复的策略是什么。

- gbro3n

2个回答

1

如果你正在使用测试数据库，SQL Diff（或类似工具）总是非常有帮助的。它有很多检查和平衡措施，保障措施以及恢复或回滚的方式，如果出现问题。非常有用。

- richard

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Michael Fredrickson · Accepted Answer

我们所有的数据库脚本都要经过多个测试阶段，针对的是与我们实际数据库类似的数据库。这样，我们就可以相当确定修改脚本会按预期工作。

对于回滚、存储过程、视图、函数、触发器等所有程序化内容都很容易回滚，只需应用对象的上一个版本即可。

正如你所提到的，挑战在于更新/删除表中的记录，甚至添加新列到表中时。你说得没错，在这种情况下，回滚同样可能失败。

我们所做的是，如果我们有一个不能轻易回滚但是是敏感/关键部分的更改… 那么我们还有一组回滚脚本也要经过同样的测试环境。我们运行更新脚本，验证其是否按预期工作，然后运行回滚脚本，并验证其是否像修改之前那样工作。

另外，我们为了预防起见，在更新之前创建一个数据库快照（SQL Server 2005）。这样，如果出现任何意外问题，我们可以使用该快照来恢复在更新期间可能丢失的数据。

因此，最安全的操作方式是针对与您的实际系统尽可能接近的数据库进行测试，并测试您的回滚脚本...以及万一这两个都失败了，请准备好快照以备不时之需。