ssdt dacpac：如何构建不同版本

Question

为当前项目中的每个版本创建两个sql脚本（更新/回滚）。我们想迁移到DACPAC解决方案。

每个DACPAC项目在en创建1个文件dacpac，因此对于每个版本，我创建2个项目（1个用于更新，1个用于回滚）。架构更改将在dacpac本身，而预脚本和后脚本用于数据迁移。

要添加新版本，我将当前更新项目复制到新的更新项目和新的回滚项目中。然后从那里修改。

有什么想法吗？

Answer 1

我想这取决于你是否需要真正完成所有这些工作，我使用SSDT的方式是定义我想要的当前版本在架构+代码中的样子以及我需要进入的任何升级脚本将部署后的文件作为可重新运行的脚本（幂等）。

如果db在版本1或100上，它们仍会获得相同的部署后脚本，但脚本会检查数据或存储在数据库中的标志，以表明特定脚本已经运行 - 应该很容易设置，但取决于您的确切要求。

为了保持这种可管理性，最好知道特定脚本何时进入所有环境，然后将其删除，这样您才能实际拥有实际需要的部署后脚本。

话虽如此，通常有一些特定的限制：

• 管理数据库的客户，因此您无法确定他们拥有的版本
• 要求升级/回滚脚本的法规（感知或其他）要求

首先了解您的要求是如何设定的，SSDT的目标是不必担心升级/降级脚本（当然是架构） - 我要问的问题是：

• 在部署之前是否足以拍摄备份或快照？
• 你可以放弃降级脚本并在需要时编写它们吗？
• 使用回滚脚本的频率（也知道前两个可以帮到这里）

如果你有一套好的测试，一个自动部署管道（即使它在某个时候有一个手动DBA步骤），那么这些问题就变得不那么重要了，随着时间的推移，每个人都学会相信这个过程会变得更快并且更容易部署更改。

你有什么限制？

版

Answer 2

如果您发现您投入了相当多的精力将逻辑投入到部署后的脚本中，那么基于迁移的方法（而不是基于状态的方法）可能更适合您

示例是DBUp（开源），ReadyRoll（这是商业用途，我们在Redgate开发的那个 - 还有其他功能，例如自动生成脚本与VS等集成）。< / p>

基于迁移的工具代表您管理版本（包括Ed所指的表格）。