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

两年前，在SQL Server论坛上，关于将测试DACPAC（就绪）生产DACPAC与部署到生产DB服务器的意图进行比较的类似问题

很明显，这是微软的某个人建议的，不推荐。这还相关吗？我们希望自动化我们的部署，使用DACPAC比较实现连续构建和部署

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

指向原始SQL论坛问题的URL链接：

---

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

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

---

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

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

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

---

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

为什么要将dacpac与dacpac进行比较？正常的情况是有一个dacpac，与您的开发服务器、QA、Prod等进行比较，因此模式都是sameTHanks@EdElliott，这有助于Hanks@StevenGreen，这非常有用。