Redgate SQL Source Control推荐了dev-test-live数据库的工作流程

Question

我们正在尝试开始使用SQL Source控件并提出一些问题。

这就是我的目标。 这看起来会起作用吗？

1. 修改dev数据库表/ procs
2. 致力于开发PC上的dev git分支
3. 将更改推送到中央仓库
4. 每次更改都重复步骤1-3
5. 将dev分支合并到测试分支中
6. 在测试分支上使用SQL Source ConGtrol“Get Latest”
7. 将更改应用于测试数据库
8. 重复步骤5 - 8但是从测试到生活

注意： - 使用“共享数据库”开发模型。

问题：

• 这看起来会起作用吗？
• SQL源代码控制是否可以将更改应用于测试和实时数据库
  • 或者我是否需要为开发服务器购买SQL Compare副本才能执行此任务？

• 修复图表： http ： //goo.gl/l2mJdt
• 我的Google文档中的更多说明和经验

Answer 1

是的，我相信这应该可行。 传统上，合并分支的问题导致迁移脚本出现问题，尽管迁移V2的测试版正在解决这个问题以及其他问题。

如果你有某种类型的构建系统链接到你的存储库，你可以自动化它部署到使用SQL Automation包进行测试的后一部分 - 例如，你可以通过执行合并然后自动触发TeamCity之类的东西更新测试以手动保存您需要执行此操作。

Answer 2

很高兴您从存储库中部署了数据库更改的版本副本，这在我眼中是非常好的持续交付实践。

对你的问题有一些建议（我戴上我的红门帽）

• 通常不建议将SQL Source Control连接到您的实时环境。 它会轮询以查找更改，这可能不是您想要的实时系统。 建议使用SQL Compare代替对UAT / Production系统进行一次性部署。 或者，您可能会对Red Gate Deployment Manager产品感兴趣。

• 您在上面询问测试中的共享/专用模式。 如果您在开发分支中为开发人员使用共享数据库，然后在测试分支中使用专用模型，则无关紧要。 如果对测试数据库的唯一更改来自一个地方（例如您的git部署），则最好以专用模式运行该数据库。

我已经绘制了一个图表 ，对你进行了一些调整。 不确定您是否使用CI服务器，但我已经添加了适合该过程的位置。 此图假设两个开发人员的专用模式，但可以是共享数据库。

Answer 3

是的，只要您使用正确的连接模型，这似乎就可以工作。

它不被Red Gate视为最佳实践（ 这就是原因 ）。 他们更喜欢你也购买SQL Compare。

您可以使用专用模型简单地连接到所有数据库，但是您无法查看谁修改了特定对象，但您可以从实时合并补丁。

我更喜欢这个：

• 开发人员使用共享模型进行连接
  • 然后你可以看到谁修改了每个表/ proc / etc。
• 我们还使用共享模型在开发服务器上保留一个工作文件夹。
  • 这允许我们使用get-latest来更新dev和来自live的补丁。

如果发布混合模型特征可能会更简单（ 在此投票）。