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

Question

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

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

1. 修改dev数据库表/ procs
2. 在dev PC上提交dev git branch
3. 将更改推送至中央仓库
4. 每次更改重复步骤1-3
5. 将dev分支合并到测试分支
6. 在测试分支上使用SQL Source ConGtrol“Get Latest”
7. 将更改应用于测试数据库
8. 重复步骤5 - 8，但是从测试到实时

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

问题：

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



• 在此处修复图表：http://goo.gl/l2mJdt
• 更多笔记＆amp;我的Google Doc
体验

Answer 1

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

如果您的某种构建系统链接到您的存储库，您可以自动化后一部分，使用SQL Automation pack进行部署以进行测试 - 例如，您可能会触发类似TeamCity的内容合并然后自动更新测试以保存手动需要它。

Answer 2

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

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

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

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

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

Answer 3

是的，只要您使用正确的连接模型，这似乎就有效。

红门（Here's why）不认为这是最佳做法。他们更喜欢你也购买SQL Compare。

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

我更喜欢这个：

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

如果a mixed model feature被释放可能会更简单（投票here）。