TEST DACPAC (READY) <=> Production DACPAC の比較に関する同様の質問は、2 年前に SQL Server フォーラムで Production DB Server に展開することを意図していました。
どうやらそれはMSの誰かによって提案されたようで、推奨されていません。これはまだ関係がありますか？DACPAC の比較を使用して継続的なビルドと展開を実現するために、展開を自動化することを望んでいました。
DACPAC の使用が推奨されないと思われる場合は、その理由を教えてください。代わりに何を提案しますか？
元の SQL フォーラムの質問への URL リンク: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/a1e5fb60-3283-4acc-b793-cb28e327dd39/using-dacpac-files-in-an-integrated -展開プロセス?フォーラム=ssdt
dacpac と dacpac を比較することは問題ありませんが、これを行うとさらに多くの問題が発生する可能性があります。たとえば、"運用 dacpac" のターゲット プラットフォームは、運用データベースの実際のプラットフォームとは異なる可能性があり、その結果、運用サーバーでは機能しない T-SQL を含むスクリプトが生成される可能性があります。または、「運用 dacpac」で指定されたデータベース オプションが、運用データベースの実際のデータベース オプションと一致しない場合があります。これにより、運用データベースでは機能しない T-SQL を含むスクリプトが生成される可能性があります。
最悪の場合、「運用 dacpac」は運用データベースと同等ではない可能性があります。つまり、「運用 dacpac」にないオブジェクトが運用データベースに存在する場合や、その逆の場合があります。これにより、意図しない側面が生じる可能性があります。スキーマやデータの損失などの影響。
これが、一般に、dacpac と dacpac を比較するのではなく、運用データベースをターゲットとして直接使用して、展開スクリプトを展開または生成することをお勧めする理由です。