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

Question

我们正在尝试开始使用 SQL 源代码控制并有一些问题。

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

1. 修改开发数据库表/过程
2. 提交到 dev PC 上的 dev git 分支
3. 将更改推送到中央仓库
4. 对每个更改重复步骤 1-3
5. 将开发分支合并到测试分支
6. 在测试分支上使用 SQL Source ConGtrol“获取最新信息”
7. 将更改应用到测试数据库
8. 重复步骤 5 - 8 但从测试到生活

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

问题：

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

• 在此处修复图表：http : //goo.gl/l2mJdt
• 我的Google 文档中的更多笔记和经验

Answer 1

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

针对您的问题提出一些建议（我戴着红门帽子）

• 通常不建议将 SQL 源代码管理连接到您的实时环境。它会轮询以查找更改，这可能不是您希望在实时系统上出现的情况。建议改用 SQL Compare 一次性部署到 UAT/生产系统。或者，您可能会对Red Gate Deployment Manager产品感兴趣。

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

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