SSDT 创建回滚部署脚本？答案

【问题标题】：SSDT creating a rollback deployment script?SSDT 创建回滚部署脚本？
【发布时间】：2013-09-24 04:42:22
【问题描述】：

我们可以使用 TFS&SSDT 创建 SQLServer 部署脚本，但是有没有办法创建回滚脚本，以便我们可以回滚部署？谢谢

【问题讨论】：

标签： sql-server tfs sql-server-data-tools

【解决方案1】：

由于 SSDT（和类似产品）都通过将项目中的架构与实时数据库进行比较以使数据库与模型同步来工作，因此没有直接的方法来创建回滚脚本。还有一些关于通过部署前或部署后脚本更改/添加/删除数据的注意事项。

话虽如此，但有几个选择。

每次发布时拍摄快照。您可以使用之前版本中的快照进行另一次比较以进行回滚。
在其他地方维护以前的版本 - 或许可以从您的生产系统与您的本地计算机进行架构比较。您可以使用它与生产进行比较并进行回滚。
在发布之前生成现有系统的 dacpac（使用 SQLPackage 或 SSDT 执行此操作）。如果出现问题，您可以使用它将该版本的架构部署回数据库。
在发布之前拍摄数据库快照。最佳情况下，您不需要它并且可以删除快照。最坏的情况，你可以用它来回滚。当然，您需要注意空间和 IO，因为您将在其他地方保持原始状态。
在多个环境中运行您的更改，以尽量减少回滚的需要。理想情况下，如果您已通过开发、QA 和暂存/用户验收环境运行此程序，那么您的代码和版本应该足够可靠，能够毫无问题地发布。

您需要相应地编写代码以回滚数据更改。这可能有点棘手，因为每种情况都不同。您需要确保编写的脚本可以撤消发布中的任何更改。如果您插入了一行，则需要一个回滚脚本来删除它。如果您更新了一堆数据，则需要备份该数据或通过其他方式将其取回。

【讨论】：

您还可以从源代码管理“发布”以前的版本。因为您使用的是源代码管理，对吧？
@MarkSowul：这不一样，是吗？如果我在两个版本之间更改单个列怎么办。如果源代码控制存储了完整的数据库模式，是否有一种简单的方法可以回滚到以前的版本，而不会删除生产数据库中的所有数据库对象？我还没有使用 SSDT，所以我只是想知道它是否可能。
假设您的数据库（和 SSDT）1.0 版有一个包含三列的表：Id INT, Name VARCHAR(10)。然后在 2.0 中，将其更改为 Id BIGINT, Name VARCHAR(10), Description VARCHAR(1000)。 SSDT 当然会改变Id 列的类型，并添加Description 列。如果您现在尝试重新发布版本 1 架构，SSDT 将删除 Description，并将 Id 更改回 INT。 SSDT 部署说“这就是我希望数据库看起来的样子”，而 SSDT 只会进行必要的更改以使架构看起来像这样。以前的版本仍然只是不同的目标架构。
种类 - SSDT 将尝试进行架构更改，但在您的 ID 为 BIGINT 的示例中，如果有人利用它输入一个大于 INT 的值，您可能会遇到问题可以处理。回滚需要一点更多处理，因为它涉及数据库中的数据，而不仅仅是模式。您真的要丢失在该新列中输入的数据吗？那个修复了一个严重错误的过程呢？也许一个修补程序是为了代替？这绝对是一个需要仔细计划并了解您为什么要回滚的领域。
对；我绝不是说这是进行完全安全回滚的灵丹妙药；只是它与您的选项 (1)、(2) 和 (3) 相同。如果您使用源代码控制，则不一定需要拍摄 SSDT 快照或 dacpacs；这相当于重新发布旧版本的 SSDT 项目。

【解决方案2】：

在对数据库项目进行任何更改之前，我会拍摄快照（dacpac），我可以将修改后的数据库项目与它进行比较以生成发布脚本。虽然交换源和目标以进行反向模式比较很容易，但我发现它不会让我从反向比较生成更新脚本（这将是回滚脚本），大概是因为目标是数据库项目。

要解决该问题并生成回滚脚本，我执行以下操作：

将修改后的数据库项目部署到我的（localdb）开发数据库中；
在进行更改之前，从源代码管理中签出数据库项目的早期版本；
运行架构比较，从以前版本的数据库项目与 (localdb) 开发数据库进行比较；
使用架构比较生成更新脚本。此更新脚本将是一个回滚脚本。

虽然能够更直接地生成回滚脚本会很好，但上面的四步过程只需不到五分钟。

【讨论】：