0

两年前在 SQL Server 论坛上，关于 TEST DACPAC (READY) <=> Production DACPAC 与部署到 Production DB Server 的比较的类似问题。

显然这是由 MS 的某人建议的，不推荐。这仍然相关吗？我们希望自动化我们的部署，使用 DACPAC 比较实现持续构建和部署。

如果您认为不推荐使用 DACPAC，请提供原因？你会建议什么？

URL 链接到原始 SQL 论坛问题： https ://social.msdn.microsoft.com/Forums/sqlserver/en-US/a1e5fb60-3283-4acc-b793-cb28e327dd39/using-dacpac-files-in-an-integrated -部署过程？论坛=ssdt

4

2 回答 2

2

将 dacpac 与 dacpac 进行比较是可以的，但这样做可能会出错。例如，“生产 dacpac”的目标平台可能与生产数据库的实际平台不同，这可能导致生成的包含 T-SQL 的脚本在生产服务器上不起作用。或者“生产 dacpac”中指定的数据库选项可能与生产数据库的实际数据库选项不匹配，这可能再次导致生成的脚本包含无法在生产数据库上运行的 T-SQL。

最糟糕的是，“生产 dacpac”可能不等同于生产数据库——即生产数据库中可能存在一些不在“生产 dacpac”中的对象，反之亦然——这可能会导致意外的一面架构或数据丢失等影响。

这就是为什么我们通常建议直接使用生产数据库作为目标而不是 dacpac 与 dacpac 比较来部署或生成部署脚本。

于 2015-08-18T17:33:21.510 回答
0

您还可以将数据库注册为 DAC，您可以在发布代码之前检测漂移。如果检测到漂移，您可以

  • 将生产中所做的更改重新添加到源代码中
  • 接受更改将被覆盖，这意味着您需要将数据库重新注册为 DAC，然后进行部署。

通过从 dev 到 prod 的标准部署过程，您可以使用漂移检测来查看是否有人做了他们不应该做的事情，并且您可以相信环境没有改变。我不建议进行 dacpac 与 dacpac 比较。

于 2017-12-21T22:22:03.077 回答