今天，我们一直在讨论数据库部署技术，在当前的过程中最近发生了几次失败，并且看到了一些情况，在这些情况下我们希望回滚部署，但是从未对旧版本的应用程序进行过测试。数据库。
一方面，存在迁移样式的部署，其中您具有版本上升指令和版本下降指令（无论是用SQL还是用您的应用程序语言编写的），并且您的应用程序知道需要获取哪个版本。
这些很简单，而且由于我们不会经常回滚，因此开发人员热衷于简单。但是，当您添加字段/表并在回滚之前填充该字段时，存在风险。或更糟糕的是，您删除了与先前版本相关的数据。
另一方面，我们可以考虑使用升级，回滚，前滚方法，其中回滚不像迁移那样剧烈。例如，升级可能会添加一个不可为空的字段；回滚使它可以为空，以便旧应用程序不在乎；前滚会填充空字段，并使它再次不可为空。
这样可以保留数据，但是代码和测试都很复杂（遗憾的是，我们几乎不存在自动集成测试，而在我们进行纠正的同时，我们也遇到了问题）。
有安全的方法来缓解这些问题吗？我还应该考虑其他选择吗？您是否想分享一些不好的经验，这些经验可以在以后帮助我减轻痛苦？
Answers:
数据库更改应像其他所有更改一样进行处理，并作为脚本进行部署（作为部署的一部分）（当然，保存在源代码管理中）。由于它们是与同一应用程序版本的代码一起部署的，因此您确切知道需要回滚什么。编写数据库脚本时，您可能会幻想并编写脚本来撤消每个更改，但是如果回滚并不常见，则可能不希望这样做。如果填充了新列，则返回原始数据库将丢失数据。
在SQL Server中，您可以在部署之前拍摄快照，然后在部署失败时立即返回快照。假设用户不在系统上时部署不会进行（您不想丢失其数据更改）。在主要发行版中，这可能非常有用，当您可能不得不降低整个系统的临时性来进行升级时。或者，您仍然可以拍摄快照，并在快照和数据库之间进行数据库比较，以查看是否需要回滚。诸如SQLCompare之类的工具甚至可以生成代码以返回快照结构。我不知道其他数据库有什么可用。
数据库结构的更改应自动/编写脚本并使用测试环境进行测试。手动更改在生产环境中风险太大
唯一合理的回滚策略（使情况恶化的可能性最小的策略）是返回到升级前的快照。如果事情出了问题，它要么会很快发生-足以使它返回快照易于管理，要么为时已晚，以至于无法回滚（由于数据库中的问题，下一个周末报告将失败）。
可以增量进行更改（例如添加字段），因此与一口气进行更改相比，进行测试的风险更低。
通过计划，您可以更改数据库以支持多个即将发布的版本，而不必面对每个版本的软件和数据库升级。
准备好在数据库升级后的第二天进入紧急模式，就像您进行软件升级一样。
抵制手动修补问题的冲动。使用您的应急策略（回滚，快照），然后再尝试升级之前考虑问题出在哪里。