我自己也在做这件事，我可以告诉你这并不容易.
首先，回答JT的回复——你不能忽略"版本"，即使SSDT有声明式更新机制.SSDT在将任何源模式移动到任何目标模式方面做了一项"相当不错"的工作(前提是你知道所有的switch 和trap )，这确实不需要验证本身，但它不知道如何管理"数据移动"(至少我看不到！).所以，就像DBProj一样，您可以在Pre/Post脚本中使用自己的设备.由于数据运动脚本依赖于已知的开始和结束模式状态，因此无法避免对数据库进行版本控制.因此，"数据运动"脚本必须应用于模式的版本化快照，这意味着您不能随意将DB从v1更新到v8，并期望数据运动脚本v2到v8正常工作(想必，您不需要v1数据运动脚本).
遗憾的是，在SSDT发布中，我看不到任何机制允许我以集成的方式处理这种情况.这意味着你必须加入自己的骗局.
第一个技巧是跟踪数据库(和SSDT项目)中的版本.我开始在DBProj中使用一个技巧，并将其带到SSDT，在做了一些研究之后，发现其他人也在使用这个技巧.您可以将DB扩展属性应用于数据库本身(称之为"BuildVersion"或"AppVersion"之类)，并将版本值应用于它.然后，您可以在SSDT项目本身中捕获此扩展属性，SSDT将其作为脚本添加(然后可以选中包含扩展属性的发布选项).然后，我使用SQLCMD变量来标识当前过程中应用的源和目标版本.一旦确定了源(项目快照)和目标(即将更新的目标数据库)之间的版本增量，就可以找到需要应用的所有快照.不幸的是，从SSDT部署开始，这是很难做到的，您可能必须将其转移到构建或部署管道(我们使用TFS自动部署，并有自定义操作来实现这一点).
下一个障碍是保留模式的快照及其关联的数据运动脚本.在这种情况下，它有助于使脚本尽可能幂等(这意味着，您可以重新运行脚本，而不会产生任何不良副作用).它有助于从只能执行一次的脚本中分离可以安全地重新运行的脚本.对于静态引用数据(字典或查找表)，我们也在做同样的事情——换句话说，我们有一个合并脚本库(每个表一个)，用于保持引用数据同步，这些脚本包含在部署后脚本中(通过SQLCMD:r命令).这里需要注意的重要一点是，如果这些引用表中的任何一个相互之间有FK引用，那么您可以按照正确的顺序执行它们.我们将它们按顺序包含在主部署后脚本中，这有助于我们创建一个工具来为我们生成这些脚本——它还解析依赖顺序.我们在"版本"结束时运行这个生成工具，以捕获静态参考数据的当前状态.所有其他数据运动脚本基本上都是特例，很可能只会一次性使用.在这种情况下，可以执行以下两种操作之一:可以对db build/app版本使用IF语句，或者可以在创建每个快照包后删除1次脚本.
请记住，SSDT将禁用FK判断约束，并仅在部署后脚本运行后重新启用它们.例如，这使您有机会填充新的非空字段(顺便说一句，您必须启用该选项为非空列生成临时"智能"默认值，以使其工作).但是，FK判断约束仅对SSDT由于架构更改而正在重新创建的表禁用.对于其他情况，您有责任确保数据运动脚本以正确的顺序运行，以避免判断约束投诉(或者手动在脚本中禁用/重新启用它们).
DACPAC可以帮助您，因为DACPAC本质上是一个快照.它将包含多个描述模式的XML文件(类似于项目的构建输出)，但在创建模式时被冻结.然后可以使用SQLPACKAGE.EXE或部署提供程序来发布该包快照.我还没有完全弄清楚如何使用DACPAC版本控制，因为它更多地与"已注册"的数据应用程序相关联，所以我们只能使用自己的版本控制方案，但我们确实将自己的版本信息放入了DACPAC文件名中.
我希望我能提供一个更具结论性和详尽的例子，但我们仍在解决这些问题.
SSDT真正糟糕的一点是，与DBProj不同，它目前不可扩展.尽管它在很多方面都比DBProj做得好，但除非在pre/post脚本中找到解决问题的方法，否则无法覆盖其默认行为.我们现在试图解决的问题之一是，当你有数千万条记录时，重新创建更新表(CCDR)的默认方法真的很糟糕.
-更新:我已经有一段时间没看到这篇文章了，但它最近很活跃，所以我想我应该补充几点重要的注意事项:如果你使用的是VS2012，2013年6月发布的SSDT现在内置了一个数据比较工具，还提供了可扩展性点——也就是说，现在，您可以为项目包含构建贡献者和部署计划修饰符.