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

Question

关于测试DACPAC (就绪) <=>生产DACPAC的比较，以及两年前在Server论坛上部署到生产数据库服务器的类似问题。

很明显，这是MS的某个人提出的，并不是推荐的。这还相关吗？我们希望我们的部署自动化，通过DACPAC比较实现持续的构建和部署。

如果您认为不建议使用DACPAC，请说明原因？那你有什么建议呢？

链接到原始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进行比较是可以的，但更多的事情在这样做时会出错。例如，"production“的目标平台可能与生产数据库的实际平台不同，这可能导致生成的脚本包含在生产服务器上无法工作的that。或者"production“中指定的数据库选项可能与生产数据库的实际数据库选项不匹配，这可能再次导致生成的脚本包含无法在生产数据库上工作的that。

最糟糕的是，"production“可能不等同于生产数据库--也就是说，生产数据库中可能存在一些不在"production”中的对象，反之亦然--这可能导致意外的副作用，如模式或数据丢失。

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

Answer 2

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

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

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