我们正在尝试开始使用 SQL 源代码控制并有一些问题。
这就是我的目标。这看起来会起作用吗？
注意： - 使用“共享数据库”开发模式。
问题：
太好了，您正在从存储库部署数据库更改的版本化副本，在我看来，这确实是一种很好的持续交付实践。
对您的问题有一些建议（我戴着红门帽）
通常不建议将 SQL 源代码控制连接到您的实时环境。它会轮询以查找更改，这可能不是您在实时系统上想要的。建议改为使用 SQL 比较来一次性部署到 UAT/生产系统。或者，您可能对Red Gate 部署管理器产品感兴趣。
您在上面询问了测试中的共享/专用模式。如果您在开发分支中为开发人员使用共享数据库，然后在测试分支中使用专用模型，这并不重要。如果对测试数据库的唯一更改来自一个地方（例如您的 git 部署），那么在专用模式下运行该数据库可能会更好。
我已经绘制了一个图表，对你的进行了一些调整。不确定您是否使用 CI 服务器，但我已经添加了适合该过程的位置。此图假定两个开发人员的专用模式，但这可能是一个共享数据库。
是的，我相信这应该可以。传统上，合并分支的问题会导致迁移脚本出现问题，尽管 Migrations V2 的测试版正在解决这个问题以及其他问题。
如果您有某种类型的构建系统链接到您的存储库，您可能会使用SQL 自动化包将其部署到测试的后半部分自动化- 例如，您可以通过合并然后自动触发 TeamCity 之类的东西更新测试以节省您手动执行的操作。
是的，只要您使用正确的连接模型，这似乎确实有效。
Red Gate 不认为这是最佳实践（原因如下）。他们希望您也购买 SQL Compare。
您可以使用专用模型简单地连接到所有数据库，但您无法查看谁修改了特定对象，但您可以合并实时补丁。
我更喜欢这个：
如果发布混合模型功能可能会更简单（在此处投票）。