dacpac到dacpac比较和部署到DB问题？

Question

关于TEST DACPAC（READY）＆lt; =＆gt;的比较的类似问题。生产DACPAC两年前打算在SQL 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-deployment-process?forum=ssdt

Answer 1

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

最糟糕的是，“生产dacpac”可能与生产数据库不相同 - 即生产数据库中可能存在一些不在“生产dacpac”中的对象，反之亦然 - 这可能导致在模式或数据丢失等非预期的副作用中。

这就是为什么一般来说，我们建议直接使用生产数据库作为目标来部署或生成部署脚本，而不是使用dacpac进行dacpac比较。

Answer 2

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

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

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