首先，您已经将此标记为Visual Studio 2012 - 如果您正在使用该版本，请确保升级到VS 2013或2015并获取最新版本的SSDT，因为每隔3个月就会发布新功能和修复版本，因此值得获取更新版本。我谈论下面的所有内容都是当前行为，我不知道在Visual Studio 2012中的原始SSDT中是否都可用。
有几件事要说，首先您可以使用/p：BlockWhenDriftDetected来强制执行有序部署，并结合将数据库注册为数据层应用程序（/p：RegisterDataTierApplication）。这将允许您执行以下操作：
1.构建dacpac 1
2.部署dacpac 1
3.构建dacpac 2
4.部署dacpac 2
5.构建dacpac 3
它会阻止您在部署dacpac 1之前部署dacpac 2，但并不理想，因为如果在部署dacpac 2之前就构建了dacpac 3，那么您将无法部署而不重新构建dacpac 3，因此不是理想的选择。
当您处理数据库的更改（任何RDBMS而不仅仅是SQL Server）时，有时候我们需要分阶段发布更改，对我而言，这更多是一个过程问题，而不是技术问题。 我所做的是：
1. 创建更改的第一部分
2. 在待办事项列表中创建一个工单以完成更改
3. 部署更改
4. 在部署后的未来迭代中，接手该工单以完成更改
5. 部署最终版本
需要注意以下几点：
1.这需要纪律性，以确保您整理和完成工作，以敏捷的方式工作并不意味着要草率 :)
2.您编写的任何脚本都应该是幂等的，因此如果要设置一些静态数据等，请使用if exists检查或合并语句，如果修改任何模式对象，则包装在if exists中等。如果您这样做，将发现部署更简单。
如果您采用此流程而不是依赖版本控制类型的策略，则无需担心部署dacpac的顺序，如果脚本很重要，请将其保留在发布后的脚本中，并检查脚本是否需要执行任何操作。如果您的脚本变得太大，则可以使用:r sqlcmd导入将它们分成不同的文件。我还听说过有人使用部署存储过程并从发布后的脚本中调用它们。
我更喜欢一种流程，您只需部署最新版本（或特定版本）的dacpac，这意味着您始终可以部署到该版本，无论您是要进行较新的构建还是回退到较旧的构建。
最后，对于您添加非空fk列的示例，可以通过单个dacpac的部署来完成此操作。要做到这一点，您需要执行以下操作：
- 创建新的表定义（包括非空和外键约束）
- 在您的发布后脚本中，对表进行更新，以便正确设置数据（显然使其幂等，以便需要时可以永久保留）
- 当您部署启用 /p:GenerateSmartDefaults 时
生成部署脚本时会生成以下脚本：
- 预发布脚本（如果有）
- 创建具有临时默认约束的非空列
- 删除临时约束
- 创建没有检查的外键，因此实际上未被执行
- 运行发布后脚本
- 使用“with check check”启用外键约束
我提到的 /p: 参数是您传递给 sqlpackage.exe 的参数。 如果您不使用它而使用其他方式进行部署，则通常可以将这些参数作为参数传递。 如果您遇到困难，请让我知道您如何进行部署，我可以帮助您。 有关 args 的描述，请参见https://msdn.microsoft.com/en-us/library/hh550080.aspx （sqlpackage.exe 命令行语法）。
如果您有任何问题，请告诉我，还有一些其他事情需要考虑，但是检查模式定义并自动生成部署脚本可以大大减少更改的工作量，并意味着您可以专注于更有用的事情-编写单元测试等等。
Ed
